Dropping OpenGL 2.1, OpenGL ES 2.0 and WebGL 1.0 support

[mosra]

Note: Don't panic, the main blocker is WebGL, as version 2.0 is still under heavy development and without any release date yet. I don't want to drop HTML5/NaCl support, so this change will not happen sooner than when WebGL 2.0 is officially supported in most browsers.

Current status:

• All recent desktop hardware has at least GL 3.0 (probably it's safe to assume 3.1/3.2+, but this needs more research), the only exceptions are old Intel chips (2008?) and drivers that chose to not support GL3 on older Intel HW (Mesa, the Windows one too?).
• Modern mobile hardware has GL ES 3.0, newer generations have ES 3.1 and the most recent ones have also AEP included. Needs more research, currently it seems that the engine would require hardware from at least 2013, Android 4.3 and iOS7 (when there is support for that).
• ANGLE has support for some ES 3.0 features, but it is probably not finished yet.
• WebGL is still 1.0, no timeframe on 2.0 release, although the 2.0 specs already exist and some browsers and APIs have experimental support for it already:
  • Firefox has default-to-off preference to enable WebGL 2.0
  • Nothing in Chrome (and thus in Opera) yet, seems like deeper issues along with ANGLE support
  • Nothing in IE yet, I don't know whether even WebGL 1.0 is working
  • Emscripten has experimental WebGL 2.0 support since v1.25.2 (Oct 2014), so I might try to add the support too.
• NaCl with ES 3.0 depends on WebGL 2.0 (and also ANGLE support).

Currently it looks like it won't happen sooner than in H2 2015 (possibly along with updates for next major release of desktop OpenGL, GLnext).

What the switch to ES 3.0 / GL 3.0 / WebGL 2.0 at minimum would mean (feature wishlist):

• Dropping support for old GLSL dialect (GLSL 1.2, GLSL ES 1.0), massively simplifying shader code.
• Ensured support for explicit attribute location in shaders, dropping bindAttributeLocation() calls, again massively simplifying shader code.
• All shaders will be able to make use of gl_VertexID (no hacky fullscreen triangle anymore).
• Ensured support for one- and two-component textures, removing all the dirty, undocumented and buggy tricks with GL_LUMINANCE formats.
• Ensured support for proper buffer mapping, dropping Buffer::map(MapAccess) function.
• Ensured ARB_vertex_array_object support, thus reducing the bloated Mesh class.
• Ensured ARB_framebuffer_object support on desktop, no annoying extension checks. In fact I could probably do this already, because this functionality is present WebGL and GLES, yay!
• Ensured support for floating-point textures, which finally means builtin effects, HDR, PBR and other great three-letter abbreviations.
• Ensured support for texture arrays and other functionality (also less annoying extension checks).

Switch to GL 3.1 at minimum would mean also:

• Ensured support for UBOs, so I could finally implement that and use it by default (present in ES 3.0).
• Ensured support for buffer copying (present in ES 3.0).
• Ensured support for primitive restart so I can finally implement that and properly support it in the upcoming OpenGEX importer (present in ES 3.0, I think).

Switch to GL 3.2 at minimum would mean also:

• Ensured support for sync objects (present in ES 3.0, I think)
• Cleaner context creation (always requesting core context, no fallbacks to compatibility/2.1 contexts)

[waddlesplash]

I'm a bit concerned about dropping GLES 2, as the number of devices that support GLES3 are few and far between at this point. I'm pretty associated with the Dolphin emulator, and our Android port requires GLES3 (I think for UBOs but I'm not sure) but there are some really nasty driver bugs that make it pretty hard to use (Qualcomm's drivers in particular are terrible).

Although WebGL2 probably won't get enabled until there are a lot of mobile devices with support for it anyway.

[mosra]

Yep, the quality of drivers is a very serious problem. Even on desktop, except for NVidia, implementation quality of GL4+ functionality is horrible and sometimes it looks like nobody tested given thing at all.

I remember that I read a blog post about mobile driver quality from Dolphin developers and it read like a nightmare. I hope things got better since then.

I wonder, does all newly released hardware already support GLES3 or are there still new models with GLES2 only?

[wivlaro]

Fwiw in unity we get frequent crashes on some Android devices if we enable
the GLES3 render paths. I wouldn't be surprised if there's some driver
bugs/edge cases out there. GLES 2 seems like a reasonable min spec if its
possible for now.
On 4 Jan 2015 20:59, "Vladimír Vondruš" notifications@github.com wrote:

Yep, the quality of drivers is a very serious problem. Even on desktop,
except for NVidia, implementation quality of GL4+ functionality is horrible
and sometimes it looks like nobody tested given thing at all.

I remember that I read a blog post
https://cs.dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/
about mobile driver quality from Dolphin developers and it read like a
nightmare. I hope things got better since then.

I wonder, does all newly released hardware already support GLES3 or are
there still new models with GLES2 only?

—
Reply to this email directly or view it on GitHub
#78 (comment).

[waddlesplash]

@mosra @wivlaro yes, that blog post is useful. We also have a database of driver bugs (some are desktop too) here.

[mosra]

Well, guess I was being too optimistic. Thanks for the valuable info!

[wivlaro]

Might be worth keeping an eye on this: https://developer.android.com/about/dashboards/index.html#OpenGL

[phoenixstew]

When toying with OpenGL ES on Android, the most common maximum support for OpenGL was 2.0.

[mosra]

Six years later, it finally might be the time to do this!

• Safari Preview finally has WebGL 2 enabled by default: https://twitter.com/webkit/status/1314261958711934976
• iOS and Android devices supporting just ES2 are very rare nowadays, according to Roblox stats at least: https://gist.github.com/zeux/51077c80bd7ffd4d558e3f1d9cbb2d92

Right now, Magnum's source code has about ~2k occurences of MAGNUM_TARGET_GLES2, so dropping all that might result in at least 6kLOC removed, not to mention all the now-unneeded docs about extension support 🔥

[crncnnr]

Hi! :)

Just thought I'd chime in and serve as a data point.

We discovered Magnum only a few months ago, and then we chose it precisely because it was the only library (we could find) that offered integration with third-party rendering, whilst also supporting older OpenGL versions. It's been working seamlessly so far.

Our specific use case is rendering within a VCV Rack plug-in, where rendering must be performed within its OpenGL 2.1 context. We have no control over the OpenGL version used here, and it's unlikely VCV will move to a more modern one, as they target fairly old hardware.

We're also targeting VST3, AUv3, etc. plug-in formats too, but here we own the window handle, and we're free to use an OpenGL version of our choosing (probably one with a core profile).

Magnum is a perfect fit here, allowing us to share the same rendering code between both use cases and differing OpenGL versions.

Older OpenGL isn't dead yet, and we'd appreciate it if the support remained; however, I understand maintenance is probably cumbersome, and nothing feels better than deleting a bunch of old code, so it's understandable if you do drop the support.

[mosra]

@crncnnr hi, thanks for the feedback! Good to know.

Sure, if you have a use case for GL 2.1, then it's here to stay :) The "old GL" code is pretty much complete with nothing significant missing or broken, it's well-tested and well-documented, so it's not a manintenance nightmare, it just occupies space. Most of the GL 2.1 code paths are shared with WebGL 1 and even though majority of platforms is WebGL2-capable, WebGL 1 doesn't seem dead yet either (and removing GL 2.1 while keeping WebGL 1 wouldn't make sense from the testability perspective).

It's possible that certain new features won't work with GL 2.1, but the base GL wrapper will continue to do so. (Or backporting of the new features can happen later if there's demand for it, like it happened with ImGui integration that used to be GL3+ but now works on 2.1 as well.)

Similarly I considered dropping GCC 4.8 support not so long ago, only to discover that it's still useful for manylinux packages, and thus it's still supported. Even though I have to put an occasional workaround here and there, it's not that painful either.