GNOME Bugzilla – Bug 743746
Add GLES 2.0 (and/or 3.0) profile
Last modified: 2016-04-25 19:01:50 UTC
the current GL machinery is pretty much tied to desktop GL. it would be good to have support for GLES 2.0+. a quick way to handle this would be to add a GDK_GL_PROFILE_GLES2 value to the GdkGLProfile enumeration, and then check the profile type in the various internal call sites for GL API where the feature set of GL and GLES diverge.
The primary failure I can see internally, context creation notwithstanding, is the use of GL_UNPACK_ROW_LENGTH, which isn't present in ES2 (it is in ES3, though this has much more narrow deployment). The relatively trivial, if unpleasant, workaround for that is: if (is_big_gl || is_es3) { glPixelStorei(GL_UNPACK_ROW_LENGTH, stride); glTexImage2D(...); glPixelStorei(GL_UNPACK_ROW_LENGTH, 0); } else { for (i = y; i < h; i++) glTexSubImage2D(x=x, y=i, width=w, height=1, data=(data + (i * stride)); }
for reference, there's also the EXT_unpack_subimage extension: https://www.khronos.org/registry/gles/extensions/EXT/EXT_unpack_subimage.txt which is implemented mostly by nvidia, and probably will be available on platforms support GLES 2.0 and 3.0.
Yes, sorry; I was mostly too lazy to look the name up. Mesa does implement that, and I'm pretty sure Mali and PVR do too. This mostly leaves Vivante/Freescale, but their drivers are so dysfunctional that I wouldn't be too concerned.
Created attachment 326227 [details] [review] gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ.
Created attachment 326228 [details] [review] wayland: Implement asking for a GLES context Wayland uses EGL, which allows us to ask for a GLES context.
These two patches are how I envision the public API for creating a GdkGLContext wrapping a GLES context created via EGL would work. Missing: * documentation * errors/warnings * checking the GdkGLContext:use-es bit field when using GL API that potentially has no GLES equivalent
Created attachment 326262 [details] [review] glarea: Relay the use-es flag to context creation
I've pushed the current state of affairs to wip/ebassi/gles; I was able to get stuff on screen fairly easily. Missing bits: * X11 implementation of GLES support using GLX_EXT_create_context_es2_profile * add a couple of branches checking for GLES extensions instead of GL ones * add a compile-time switch for platforms that have hw accelerated GLES but software GL
Latest update of the wip/ebassi/gles: * GLX should be able to create a GLES context (still only lightly tested) * All uses of GL vs GLES API should have been fixed * No compile time switch, as it warrants some discussion The branch is ready for review; it's about 20 commits, so I'm not sure whether to attach it to the bug as well or not.
If you want to test it, then build wip/ebassi/gles and run: GDK_GL=gles ./tests/testglarea and you should see the exact same thing as running ./tests/testglarea. I suggest using Wayland instead of X11. I'll also port the GtkGLArea gtk3-demo, as it needs updated shaders.
I've merged the wip/ebassi/gles branch in master, after testing that both Wayland and X11 backends worked. This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.