How to request the OpenGL Core profile

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

  1. If this is an intentional change or a bit of an oversite or bug
  2. 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.

You can use gtk_gl_area_set_allowed_apis() with GDK_GL_API_GL to tell GLArea to bind the GL API instead of GLES.

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.

Thanks @ebassi for clarifying all this.

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.

That’d be a Mesa bug, and you should file it on their issue tracker, if one isn’t already there. Remember to attach a full backtrace of the crash.

We are not bug-for-bug backwards compatible, true; but as long as the gl-prefer-gl value is valid in G_DEBUG, then we’re going to support it.

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])