obsproject
RFC: OpenGL ES support
Description
Add GLES support to OBS, as a compile-tile CMake option (currently only apply to Linux yet).
Motivation and Context
The main motivation of it is to support OBS on platforms w/o usable OpenGL driver, but GLES ones (currently mainly mobile PowerVR GPUs, tested on BXM-4-64).
How Has This Been Tested?
- Built and run with no new options added (with GL) on a Mesa (Intel/AMD) GL driver.
- Built and run with USE_GLES=ON on a Mesa GLES driver.
- Built and run with USE_GLES=ON on the target Imagination driver system.
Types of changes
- New feature (non-breaking change which adds functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [ ] I have included updates to all appropriate documentation.
Well GLES-only situation is currently quite popular on RISC-V (and at least used to be on ARM).
In addition, according to some comments in Qt 6, the NVIDIA Linux driver discourage to use EGL+GL, which is what obs uses now on both X11 and Wayland.
However, if there's really no interest on merging this, I think I could maintain a seperate fork for this instead.
I'm not necessarily opposed to having gles if it actually enabled more hardware, but I dont really see that being the case. https://mesamatrix.net/ shows that every mesa gles 3.2 driver also support gl 4.6, so this doesnt appear to be expanding to any mesa covered hardware.
Well GLES-only situation is currently quite popular on RISC-V (and at least used to be on ARM).
We don't support either of those platforms (yet). We intend to support ARM but mainly for Apple Silicon and things like the new Snapdragon chips, which should support full OpenGL.
In addition, according to some comments in Qt 6, the NVIDIA Linux driver discourage to use EGL+GL, which is what obs uses now on both X11 and Wayland.
Would EGL+GLES be any better there? But we intend to move to Vulkan anyway.
However, if there's really no interest on merging this, I think I could maintain a seperate fork for this instead.
I'll let out Linux people have the final say on this, but you are of course welcome to maintain patches, it's just unlikely to be something that we want to maintain upstream.
Thank you for your contribution. I'm going to make the decision to close this for now, given the comments above. If it's demonstrated to me that this has tangible benefits worth the increased maintenance, then we'll reconsider at that time.
