Migrating to OpenGL 4.0 core profile

Development
1

tldr; I’ll need some folks to help test a new OpenGL 4.0 build, particularly on Windows and Linux, where hardware esp. GPU and drivers are more diverse.

I had been putting it off for a while, but recent bug reports about Nvidia drivers on Linux pushed me to make progress on OpenGL 4.0 compatibility.

As far as I can tell, hardware and drivers supporting OpenGL 4.0 have been shipped since 2012. (Even on macOS, with Apple threatening to deprecate OpenGL)

So I think we’re good. Performance definitely seems better, but I’ll have to find something really huge to truly benchmark.

My plan is to “flip the switch” tonight and we’ll have ~2 weeks before 2.0 to get in more testing.

2

This is from a build with these pull requests on Fedora 43 KDE, with proprietary Nvidia drivers, version 580.119.02.

avogadro2.log (5.2 KB)

3

Thanks…

The key section is:

QEGLPlatformContext: Failed to create context: 3009
QRhiGles2: Failed to create temporary context
QEGLPlatformContext: Failed to create context: 3009
QRhiGles2: Failed to create context
Failed to create QRhi for QBackingStoreRhiSupport
QEGLPlatformContext: Failed to create context: 3009
QOpenGLWidget: Failed to create context
QEGLPlatformContext: Failed to create context: 3009
QOpenGLWidget: Failed to create context

In other words, either your driver or your Qt doesn’t support OpenGL 4.0.

You can run glxinfo | grep "version" to get info on your driver.

But doing some Googling, suggests this is pretty widespread (e.g., Cura 3D printing among many, many others)

The first suggestion for many is to run with QT_QPA_PLATFORM=xcb

A few other suggestions to try:

  • export QT_XCB_GL_INTEGRATION=xcb_glx which forces GLX instead of EGL
  • export QT_OPENGL=desktop (if that works, we can add QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL); to avogadro.cpp)

Actually if the QT_OPENGL=desktop works, let’s try patching avogadro.cpp since that would be easier.

4 
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL core profile version string: 4.6.0 NVIDIA 580.119.02
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL version string: 4.6.0 NVIDIA 580.119.02
OpenGL shading language version string: 4.60 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 580.119.02
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
    GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions,

The only one of these that worked was QT_QPA_PLATFORM=xcb. The others gave the same errors as before.

5

If you’re saying that works, and you’ve got visible atoms, bonds and orbitals, then I think I’ll go ahead and merge for further testing.

6

Yup. All three work.

1 Like
7

Won’t that cause it to run on X11?

8

What I merged into the AppImage is:

# Only force xcb if on Wayland and user hasn't set a preference
if [ -n "$WAYLAND_DISPLAY" ] && [ -z "$QT_QPA_PLATFORM" ]; then
    export QT_QPA_PLATFORM=xcb
fi

In other words, based on user reports (not just @brockdyer03 but others on the GitHub issues) it seems as if this is a fairly common problem. You can find lots of apps with similar error issues with some Google searching.

If you, or others can get it working on Wayland, great, you can explicitly set QT_QPA_PLATFORM

But IMHO, the default for the AppImage or Flatpak is a user expectation that “it just works”

9

OK, but there were other issues that were fixed by moving to Wayland in the first place, which this would then undo. And undo them for all users, even though it’s fairly likely that the errors are caused by the NVIDIA drivers, which are infamously problematic under Linux, and affect only a small subset of Linux users.

10

If you’ve got a better fix, I absolutely welcome ideas.

11

Well, I would argue that it makes more sense to keep the default as Wayland and that NVIDIA users (assuming that it is indeed entirely an NVIDIA problem) can be the ones who set QT_QPA_PLATFORM=xcb, rather than regressing and making the experience worse for everyone else.

Or, alternatively, add a third condition to the if statement, so that it’s only set to use xcb if:

  1. on Wayland
  2. QT_QPA_PLATFORM isn’t set
  3. the GPU vendor is NVIDIA (via Qt3DRender::QRenderCapabilities Class | Qt 3D | Qt 6.10.1 perhaps?)
12

Okay, but we’d need some way to detect from a shell script. We can’t use Qt because we can’t change to xcb after we launch.

I don’t have access to a Linux box with Wayland and Nvidia, so I can’t do much to test.

Maybe something with glxinfo?

glxinfo | grep "OpenGL core profile version" | grep "NVIDIA"

As I said, I’m absolutely open to suggestions. It’s pretty easy to patch:

13

By the way, does this mean we don’t need GLEW any more?

14

I don’t know if GLEW is needed. I guess in principle, Qt can handle creating the context?

I’ll try that later - I have a bunch on my plate right now.

15

Oh no, there’s rush to change anything at all! I was wondering whether it was no longer even a dependency after the switch and whether I should stop building it for the Flatpak, that’s all.