I have a GK4 application that uses OpenGL via the GLArea widget. I just upgraded to Fedora 40 and the application now fails under Wayland.
It fails because the Shaders are set at version 330, which isn’t supported under ES profile
What happens under Wayland is that the OpenGL ES profile is used.
I have been able to update my code, updating the shaders and a couple of other minor bits of code, but would like to know and be able to document for others
If this is an intentional change or a bit of an oversite or bug
If I can request the 'core" profile somehow and how I can do this.
I added some debug lines to a test case to pring the GL version/vendor/renderer info and
under wayland get
GL_Version “OpenGL ES 3.2 Mesa 24.0.5”
GL_Vendor “Intel”
GL_Renderer “Mesa Intel(R) HD Graphics 630 (KBL GT2)”
under Xorg (x11) get
GL_Version “4.6 (Core Profile) Mesa 24.0.5”
GL_Vendor “Intel”
GL_Renderer “Mesa Intel(R) HD Graphics 630 (KBL GT2)”
Yes, it is intentional: GLES gives us more coverage across a more varied spectrum of platforms and devices, and allows us to use zero-copy paths to shared hardware buffers like dmabuf.
Just be careful that unlike Mesa, some drivers—namely, older versions of the closed source nVidia binary driver—do not allow mixing GL and GLES. If that happens, you can use the GDK_DEBUG environment variable, and set GDK_DEBUG=gl-prefer-gl in your environment to tell GTK to prefer GL instead of GLES.
btw, under Mesa there’s also some issues with switching to OpenGL profile resulting in possible app crash. True that can be workarounded with gl-prefer-gl code path in current versions, and no guarantee in future versions if I got it correctly.
I’m not sure, if that’s related to Mesa itself
for example (testing that on different OSes, some ones in VM, some not) on Fedora 40 there’s
No provider of glMapNamedBuffer found. Requires one of:
Desktop OpenGL 4.5
GL_ARB_direct_state_access
Aborted (core dumped)
or
No provider of glNamedBufferSubData found. Requires one of:
Desktop OpenGL 4.5
GL_ARB_direct_state_access
GL_EXT_direct_state_access
Aborted (core dumped)
and at the same time it works without aborting on one of ArchLinuses with the same Mesa version and renderer type. And many debian derived OSes but with distinct Mesa versions.
I.e. it’s a bit labyrinthine to find out which part of software can cause it on some particular OS and software combination. Suppose that the only clear way to follow GTK/GDK GLish, at least it’s easier than debug it.
The abort() message in this case is coming from libepoxy, and it has nothing to do with GTK: it’s the basic GL/GLES feature detection mechanism. You cannot use API that is provided by an extension if the extension isn’t available; the same applies to GL version checking.
In other words: your own GL/GLES code must be able to cope with different versions of GL regardless of whatever GTK does.
Is it an epoxy bug? if there’s no aborts while running with GDK_DEBUG=gl-prefer-gl app, and it aborts on kind glNamedBufferSubData()/glMapNamedBuffer() functions only at the GTK/GDK switching to GL from GLES on some combination underlying OS/software
It’s not: libepoxy asserts whenever you try to use an API that is not available.
Yes, this is what I have been saying the whole time: you cannot use GL API if the current context is a GLES one, or use GLES API if the current context is GL. You have to select the correct API, and then you have to check the API, version, and extensions available before using the API.
This isn’t something new: all of GL works this way.
of course it’s done by calling gtk_gl_area_set_allowed_apis(, GDK_GL_API_GL) and checkout with gtk_gl_area_get_allowed_apis(). And glGetString() reports GL core profile too. And then it aborts (on Fedora40 [note: 3D GL drawing works there except functions reloading buffer data])