X windows and XQuartz on ARCHER

Paraview and ARCHER

Every so often we get an ARCHER query where Paraview isn't working for somebody. As Paraview requires remote window functionality (X Servers) and can also do offscreen rendering and all sorts of other things, it can be complicated to get it working properly and efficiently. 

We have a relatively complicated port forwarding setup that can be enabled to allow people to run the Paraview client on their local machine (desktop/laptop) and connect to a pvserver instance running on the ARCHER or RDF compute nodes to visualise and steer what pvserver is doing. This can be a quicker and more efficient way of running the Paraview client (I find running the client across an X Server connection very slow).

Figure 1: Example glxgears output

Because it is a complicated setup, it can cause problems for users. However, the problem I'm talking about here isn't to do with Paraview or port forwarding at all. What happens is the user tries to open Paraview, the window opens, but... it's blank.

XQuartz

This only affects Mac users, and is to do with the XQuartz software used to display remote windows and how it processes OpenGL instructions (or GLX instructions). The same phenomenon can also be experienced without using Paraview at all, the glxgears test program will also display a blank screen when it should show rotating gears (as in Figure 1).

The application run (Paraview, glxgears, etc...) will also provide some error information, for example:

name of display: localhost:27.0 libGL error: failed to load driver: swrast libGL error: Try again with LIBGL_DEBUG=verbose for more details. X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 22 Current serial number in output stream: 23

You can get more information on the OpenGL/X setup you are using through the glxinfo command (running this on the remote window should provide a lot of information about the specific X windows/OpenGL configuration you have). If you see the bug it is likely that the glxinfo will say that you are using indirect rendering (direct rendering: No).

What is actually going wrong for the users who report this query on ARCHER is that there is a bug in XQuartz, the X windows server that can be used on OS X (Apple Mac), that causes GLX for indirect rendering not to work. This bug appeared in XQuartz 2.7.9 and should be fixed an upcoming version of XQuartz, but it isn't fixed yet.

This problem may be avoided by using this on the remote client:

export LIBGL_ALWAYS_INDIRECT=1

But if this doesn't work you will have to downgrade XQuartz to version 2.7.8 until the fix is available in the latest version, and then GLX windows should work for you.

Thanks to Manos for his contribution to this work.