cogl: Remove legacy OpenGL driver support
This means the two Cogl drivers left are OpenGL >= 3.1 and GLES >= 2.0.
Putting this out here.. are there really any drivers that only support legacy OpenGL but not GLES 2.0?
Merge request reports
Activity
added ~10273 5. Cogl labels
Intel Gen3-Gen5 (GPU families not CPU families) come to mind, which Wikipedia says are only OpenGL 2.1 but should support ES 2.0.
We get a few bug reports per year from users of those. I guess we just need to verify that it falls back to ES 2.0 reliably.
Edited by Daniel van VugtIntel Gen3-Gen5 (GPU families not CPU families) come to mind, which Wikipedia says are only OpenGL 2.1 but should support ES 2.0.
Does that Wikipedia list apply to mesa?
We get a few bug reports per year from users of those. I guess we just need to verify that it falls back to ES 2.0 reliably.
Makes sense.
In fact, older Intel only expose GLES 2.0 and had their partially software emulated GL 2.1/2.0 support dropped: https://www.phoronix.com/news/OpenGL-1.4-i915-Now-Default
@vanvugt any chance you remember which device you were thinking about? I'm relatively sure there's no Mesa driver where this would be the case - and definitely not on old Intel - so I wonder what it could have been. ARM devices seem unlikely - what's left then, extremely old Nvidia? Odd proprietary drivers? If it's only the later case I'd be tempted to simply not care.
Edited by Robert MaderI don't remember sorry. But by coincidence I did see mention of Raspberry Pi in that category today: totem#523 (closed)
In fact, older Intel only expose GLES 2.0 and had their partially software emulated GL 2.1/2.0 support dropped: https://www.phoronix.com/news/OpenGL-1.4-i915-Now-Default
@rmader that statement is not correct. The support is not dropped, it is disabled by default to workaround applications that don't implement any check to prefer their own software renderer if that's faster.
To say it otherwise, because Google Chrome didn't implemented any check to select their faster code, Mesa disabled the feature by default for every applications to force the specific Google Chrome application to fallback on their faster code.
The support is still there and shipped. Applications needing GL 2.1/2.0 can request it at run time this way:
https://github.com/DaemonEngine/Daemon/commit/26d766988dd41098413a52dd3974cf23e7f32701
Edit: That Phoronix post doesn't say the support is dropped, but that the default exposed version dropped from 2.1 to 1.4, which has not the same meaning at all. The rest of the article just says exactly what I said: “But the latest Mesa code will at least continue to expose OpenGL ES 2.0 and the OpenGL 2 support can be restored if setting the fragment_shader and stub_occlusion_query options.”. This setting (and then the restoration) is done at runtime.
Edited by Thomas Debesse
added 507 commits
-
34de2aa0...c6b454d0 - 505 commits from branch
GNOME:main
- 58771c52 - clutter: Remove some unused macros
- 3ab760a6 - cogl: Remove legacy OpenGL driver support
-
34de2aa0...c6b454d0 - 505 commits from branch
- Resolved by Robert Mader
This apparently needs a bit more cleanup in the tests.
The main benefit I personally see from this MR is that we'd use GLES instead of GL on low-end hardware - and from the hardware I have in mind I'd expect that to either run equally well (old Intel) or even slightly better (some ARM SoCs). That, however, could of course also be archived by simply preferring the GLES2 over the legacy GL backend.
Apart from that I'd like to only have to test two variants when it comes to new shader-based features like YUV support and, possibly, color management.
I haven't seen evidence of real issues with the legacy GL backend though.
There was something in some other merge request that triggered this, but can't remember if it was a insignificant annoyance or something bigger, but since I didn't mention what it was, perhaps it was nothing in particular. I'd be fine with leaving it in, and remove it if something comes up that is too annoying with GL < 3.
assigned to @marge-bot
requested review from @rmader
changed milestone to %GNOME 44
mentioned in commit jadahl/mutter@e5195c08
mentioned in commit jadahl/mutter@b2579750
added 12 commits
-
351ae67f...5b5b1165 - 10 commits from branch
GNOME:main
- e5195c08 - clutter: Remove some unused macros
- b2579750 - cogl: Remove legacy OpenGL driver support
-
351ae67f...5b5b1165 - 10 commits from branch
mentioned in issue #2745
@jadahl hey, how to know if mutter is running on gles or gl... I am on an arm linix platform on lunar.. and would be nice to know. It should default to gles on arm platforms, but bc we also have gl 3.1 on many, it may trying to use opengl, something a bit slower, but a major degree sometimes.