GNOME Bugzilla – Bug 777325
Support EGL for creating GL contexts on X11
Last modified: 2018-05-02 17:58:53 UTC
The X11 platform has two GL native API: - GLX - EGL with support for X11 surfaces GDK supports the former, but not the latter. There are various use cases for supporting EGL-X11: - various embedded hardware platforms support OpenGL ES and EGL, and have native X11 drivers, but as they don't support OpenGL, they don't usually come with GLX drivers - newer Linux features, like passing around zero-copy dmabuf objects can be handled using EGL and platform-specific extensions, but they cannot be implemented using GLX We can definitely add a configure-time option for building GTK+ with a specific API; we should also add an option to specify whether GTK+ should default to OpenGL or OpenGL ES. These options are useful for system integrators that know and control which platform they are building GTK+ for. There are some issues with selecting whether to use GLX or EGL-X11, and then selecting OpenGL or OpenGL ES at run time. On the embedded hardware side, there's the added complexity that the platform may have Mesa installed, which means that selecting GLX first will result in a perfectly working GL software rasterizer, instead of the hardware accelerated option. We cannot really drop GLX, mostly because not every desktop system supports EGL out of the box on X11. A plausible attempt at a solution is: * add a `--with-x11-opengl-api=auto|glx|egl` configure-time option, to allow selecting which GL native API should be used; `auto` detects support for GLX and EGL, and does a run-time check * add a `--with-default-opengl-api=auto|gl|gles` configure-time option, to allow selecting the default GL API between OpenGL and OpenGL ES; this determines the default value of GdkGLContext.use_es when use_es is set to "-1" (platform default); if `auto` is selected, we keep the current behaviour of checking via epoxy if the currently bound API is "desktop GL" * when using the X11 backend, we check whether EGL is supported, and default to it; if it's not available, we fall back to GLX This changes the default platform API from GLX to EGL-X11; we need to check with various stakeholders in the X.org community whether or not it's a good plan. An initial implementation of the EGL-X11 support can be found in the wip/ebassi/gdk-egl-x11 branch: https://git.gnome.org/browse/gtk+/log/?h=wip/ebassi/gdk-egl-x11 What's missing from that branch: - configure time option for selecting between GL and GLES default - build both GLX and EGL-X11 GdkGLContext - default to EGL-X11 and fall back to GLX
From: https://www.phoronix.com/scan.php?page=news_item&px=MTE3MTI Also mentioned by Eric is "GLX is pretty much deprecated at this point." Intel is encouraging developers to use EGL rather than GLX. EGL is needed anyways for Wayland, Android, OS X, etc and the Mesa EGL support has matured quite well and still works fine with an X.Org Server. Eric said, "Please please please stop using GLX. There shouldn't be anything left that GLX has that EGL doesn't."
From IRC: < ebassi> airlied: ajax: anholt: Quick question for you. If GTK+ started using EGL-X11 by default (with GLX as a fallback) would we see any issues from Mesa/Xorg? < airlied> ebassi: should be fine, but im sure some subtle things might sneak in < anholt> ebassi: none that I know of. < ajax> ebassi: i can vaguely imagine there might be some GLX extensions not equally reflected into EGL. if you find any you care about, i'd call them bugs worth fixing. < anholt> there's also a bit of "egl-on-x11 has been pounded on less by non-testcase apps than glx has." but what ajax said. So, I guess we have an endorsement for switching to EGL-X11 by default. Currently, the GLX extensions we use are: * GLX_ARB_create_context_profile * GLX_EXT_create_context_es2_profile * GLX_SGI_swap_control * GLX_EXT_texture_from_pixmap * GLX_SGI_video_sync * GLX_EXT_buffer_age * GLX_OML_sync_control * GLX_ARB_multisample * GLX_EXT_visual_rating We don't need most of these for EGL: we don't use multi-sampling for our primitives; we tend to disable swap control, because we are compositor-driven; we don't need an extension to create a GLES profile in EGL. EGL has sync control (even though we end up disabling it when running under a compositor) and has the buffer age extension. The major change is the visual rating, since we would not be caching visuals with EGL-X11; we'd have to check how nVidia deals with EGL-X11, but maybe we will have to blacklist that GL renderer and automatically fall back to GLX for it. Landing this in GTK+ 3.x will also need some integration with Clutter, to let Clutter-GTK continue working.
Any update on this branch, Emmanuele ?
Yes; I got sidetracked a bit by other work, but I plan to push it ASAP. I wanted to test with applications that still use Clutter-GTK to avoid breaking them, and I also wanted to test on the ARM Mali platform that Endless ships, to ensure that it keeps working.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/738.