X-windows GLX for remote OpenGL acceleration

Running X-windows remote with OpenGL hardware acceleration

GLX ("OpenGL Graphics with the X Window System") is an X11 extension allowing you to use your GPUs hardware acceleration even across the network - but it isn't trivial getting it to work.

Normally running the X-server and client on the same machine, the client may use Direct Rendering Infrastructure (DRI) for best performance. This is however not possible running across a network.

However, the Xorg X-server in most GNU/Linux distributions disables indirect rendering. To enable it, you must start the X-server with the +iglx option

E.g. using lightdm; /etc/lightdm/lightdm.conf:

xserver-command=X +iglx

For best performance, if the network is trusted, you can also activate native X over the network (i.e. not tunneling X11 over SSH, but using TCP);

xserver-command=X +iglx -listen

Now you can start your X11 clients (assuming proper authentication, see xhost):

$ glxgears --display myXserver:0

Unfortunately, glxgears is about the only OpenGL program you'll be able to run (exaggeration, but you get the gist). This is because you are very likely running the Mesa GLX implementation client side (glxinfo shows you). But do not despair - your graphic card manufacturer probably got a better implementation. At least Nvidia (thank you guys!). But guess what? It is also disabled by default ...

Time to mock around with your /etc/X11/xorg.conf:

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1050 Ti"
    Option         "AllowUnofficialGLXProtocol" "true"
EndSection

Notice the last option. This does the trick. Now more advanced OpenGL program such as Blender will work. Don't care about what "OpenGL version" is supported, but "which GLX extensions" are. The AllowUnofficialGLXProtocol simply enables a bunch more of 'em. The latest version of GLX is version 1.4 and it supports OpenGL version 1.3 (how wonderful intuitive, isn't it?), but an implementation may still do better than this by "extending" the standard. This option enables GLX extensions supporting up to OpenGL 3.2, although cherry picked and no way complete it seems to do the trick for many applications.

As a developer, though, you want to keep in mind that if you stick to OpenGL 1.3 then GLX will work for just about every GLX implementation, including Mesa. And no, I'm not badmouthing Mesa, I'm sure it implements the standard by the book - it is the book I'm badmouthing. :-) But please don't code for higher than OpenGL 1.3 if you don't need. But if you need for performance - go for it! You won't play Kerbal Space Program or the latest Steam title over the network anyway.

One caveat in the Nvidia implementation. "Sync to VBlank" (i.e. syncing the frame update with the display update frequency) seems buggy. Using this configuration and stuff such as glxgears will likely freeze. You have to disable sync to vblank as well.

$ nvidia-settings -a SyncToVBlank=0

And no, there's no xorg.conf-option for this. Also note that you must install the nvidia drivers on both the X-server as well as on the client machine, even if the client machine doesn't even got a GPU. This because you'll need the Nvidia GLX implementation both server side as well as client side. The nvidia-glx package is sufficient, but if you want nivdia-settings as well, you'll probably ending up installing everything nvidia but the kitchen sink due to dependencies. This is really not a problem.

To avoid warnings about indirect rendering used, you may set an environment variable client side;

$ export LIBGL_ALWAYS_INDIRECT=1

Two other client side environment variables are documented by Nvidia as well;

__GL_ALLOW_UNOFFICIAL_PROTOCOL=1
__GL_SYNC_TO_VBLANK=0

Unfortunately these variables seems to do nothing. The first seems not to be needed, the second does nothing. At least not in the driver versions I've tested.

Now you probably got several GLX implementations installed on your machine (mesa and nvidia). You can switch between them by using the update-glx program. I have not found any neat solution using different GLX simultaneous on the same (X client) machine though (for users at different [kind of] X-servers, of course). Playing around with the dynamic linker LD_* variables would probably do the trick.

Why bother with this?

X-Windows is the native window system for many systems. Running them remote (and/or virtualized) often involve different solutions for remote access such as VNC, vSphere client, spice, NX etc, despite of that those solutions basically solves the same problem X11 intended to. I prefer keeping the number of different concepts as low as possible, especially avoiding non-standard often proprietary solutions.

References

Feedback? Questions? Suggestions?

This tutorial too basic? Too complicated? Please feel free to send me a mail!

/By Mikael Q Kuisma