nVidia’s OpenGL sample code gl_cadscene_rendertechniques in nvpro cannot creat window: GLX: Failed to create context: GLXBadFBConfig

Gaming and Visualization Technologies APIs OpenGL
1

I managed to build nVidia’s OpenGL sample code gl_cadscene_rendertechniques in nvpro. However, when I run the generated executable gl_cadscene_rendertechniques.exe, I got an error:

GLX: Failed to create context: GLXBadFBConfig
Could not create window

If I set LIBGL_DEBUG=verbose and LIBGL_ALWAYS_INDIRECT=0, more error messages can be displayed:

libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file $HOME/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file $HOME/.drirc: No such file or directory.
GLX: Failed to create context: GLXBadFBConfig
Could not create window

To troubleshoot, I built glfw shipped with nvpro (in nvpro-samples/nvpro_core/third_party/glfw). On the Ubuntu client, all OpenGL sample and test codes work as expected. On Windows client, windows works (surprisingly), Some (like triangle-opengl) reports the same error, some (like boing) errors:

X Error of failed request:  BadRequest (invalid request code or no such operation)
  Major opcode of failed request:  149 (GLX)
  Minor opcode of failed request:  16 (X_GLXVendorPrivate)
  Serial number of failed request:  146
  Current serial number in output stream:  148

Of course, nVidia’s sample code has no problem. So, it must be the fault of the system where I compile and run these samples. But what’s the problem? How can I fix it to run gl_cadscene_rendertechniques.exe?

My environment:
Remote side:

  • Ubuntu 20.04
  • GPU: GeForce RTX 3090, Driver Version: 460.32.03
  • GLX server version is 1.2 if using Xming, 1.4 for all other cases
  • ssh and X server are both on.

Client side 1:

  • Ubuntu 20.04
  • Software renderer: 3.1 Mesa 20.3.2 which supports OpenGL 4.5
  • Connect using ssh -X

Client side 2:

  • Windows 10,
  • GPU: Quadro K5200, driver version 472.12
  • X server: Xming 6.9.0.24 or VcXdrv X Server 1.20.9.0
  • Connect using Bitvise SSH Client 8.49 with xterm terminal and X11 Forwarding enabled
2

To clarify, can you share a bit more detail?

Are you building the Windows .exe on the Remote host? I am not too familiar with this kind of setup, but are you correctly set up for cross-compilation?
When running then GL apps on the Windows client, you are forwarding it with the help of a X Server running on the Windows Client? Did you already try connecting with a Windows tool like RDP and bypass the X server? Or run only locally?
I don’t think that the X Server on Windows would support the GPU when running GL apps on it, since the driver is Windows native.

3

Sure, I’m glad to share more details.

For the first paragraph of questions:

The gl_cadscene_rendertechniques sample is built on the remote host running Ubuntu 20.04. First I run cmake in build folder created in nvpro-samples/gl_cadscene_rendertechniques:

cmake .. -DX11_Xrandr_INCLUDE_PATH=$HOME/.bin/usr/include/X11/extensions -DX11_Xinerama_INCLUDE_PATH=$HOME/.bin/usr/include/X11/extensions -DX11_Xcursor_INCLUDE_PATH=$HOME/.bin/usr/include -DX11_Xi_INCLUDE_PATH=$HOME/.bin/usr/include/X11/extensions

The remote machine does not have some of X development packages installed so I have to install them in my user space. I did not specify platform to Windows in cmake, so I think it should default to Linux platform, not a cross-compilation. Then I cd to nvpro-samples/gl_cadscene_rendertechniques to run make and make install. It generates the executable to nvpro-samples/bin_x64/Release/gl_cadscene_rendertechniques.exe. I don’t understand why the executable has an extension .exe which is not a default behavior. But I use file command to confirm that the executable is for Linux, not for Windows:

 gl_cadscene_rendertechniques.exe: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=dceec49807f58a4a8b39b46b99fbaf25b15796f8, for GNU/Linux 3.2.0, not stripped

If it were a Windows executable (PE), the Ubuntu loader would reject to run it and give a different error message instead of “GLXBadFBConfig”.

For the second paragraph of questions:

I’m running gl_cadscene_rendertechniques.exe in ssh with X Forwarding enabled. Here, this executable is a X client. On Windows (Client side 2), the Xming or VcXdrv acts as a X server. So, the OpenGL commands issued by gl_cadscene_rendertechniques.exe are supposed to be delivered to these Windows X server for rendering. Since X server does not support OpenGL directly due to its design policy, an extension to X, GLX, is needed to interpret OpenGL commands and render on Windows. This is my shallow understanding of X system, please correct me if I am wrong. But I can’t see any problem with this settings because X utilities like xeyes, xclock and even FireFox browser can run properly in this settings. The graphic output in glxgears window freezes but the program runs and reports correct data in ssh console. I’m still studying GLX so maybe the GLX to these Windows X server has problem; I don’t know as of now. But the same problem occurs in Ubuntu client (Client side 1). This is a guest VM OS in the same Windows machine and everything related to GUI is installed and most up-to-date. It is also given enough GPU memory (3GB, the best VMWare Workstation can allocate, and Windows Task Manager tells me that 3GB is really allocated). Ubuntu should have no problem with X or GLX, which are Ubuntu’s native drivers, but the same “GLXBadFBConfig” error happens.

I don’t think Windows RDP can connect to Ubuntu directly (the remote machine did not config for this using VNC or some 3rd-party software). I am not allowed to access the remote machine so I can’t run gl_cadscene_rendertechniques.exe locally. I have searched google for GLXBadFBConfig GLX error, but none of the solutions applies to this issue. I’m trying to set up remote debugging environment these days, but as a normal user, the software I can install is very limited. If the problem is in glfw initialization stage, I can focus on debugging this piece of code, but nvpro sample is so big that I can’t even figure out where the glfw initilization code is for gl_cadscene_rendertechniques. Please let me know if you happen to know it so that I can isolate the problematic code. Thanks.

4

gl_cadscene_rendertechniques requires OpenGL 4 to render, as per its doc. So, these days I had thought VMware Workstation limits the version of OpenGL to 3.3. As a result, I installed Qemu 6.2 on Windows and Ubuntu 20.04 in Qemu, and installed the latest mesa drivers which support OpenGL 4.5 in the guest. Now the glxinfo in guest Ubuntu clearly reports OpenGL version 4.5, but the same error of “GLXBadFBConfig” persists. There is no X11-Forwarding now, only Virtio-GPU that supports direct rendering on my Windows GPU. Is this sample designed only for Windows? Has anyone ever successfully run this sample on Ubuntu?

5

Hi again,

Thank you for the very detailed breakdown of your setup and what you tried so far.

Unfortunately even after talking to colleagues it is very hard to figure out where the issue(s) might be since this is such a non-standard scenario. From the information you have given it seems you have done everything right.
The only guess is that there is still some driver version mismatch or a missing configuration to enable GPU pass-through.

We are working on some documentation on how to successfully set up a remote session much like you tried in your initial post. The process to get that running is definitely not straightforward. I can’t tell yet when it will be available, but I will make sure to pin it in this forum.

One thing I can help you with right now is to point you to the glfw initialization. Much of the OpenGL boilerplate is part of nvpro-core. And the main sub-directories for that are nvpro-core/nvp where you will find glfw initialization and nvpro-core/nvgl with more GL helpers.

Finally yes, the samples should run on both Linux and Windows.

Sorry if I can’t give much more advice at the moment, but please keep us posted about your progress.