-
-
Notifications
You must be signed in to change notification settings - Fork 7.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: OpenGL ES support #10977
RFC: OpenGL ES support #10977
Conversation
ESSL does not allow implicit type conversion. Fix some shaders that use integer constant to compute with float variables. Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
The OpenGL software expects the shader to output a vec4, and when a vec3 is returned, the result is undefined according to the OpenGL specification. Fix this type mismatch by expitcitly define alpha value. Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
glMapBuffer's OpenGL ES counterpart, defined in GL_OES_mapbuffer extension, only supports writing. Switch to glMapBufferRange, which is a common function in desktop GL 3.0+ and GL ES 3.0+. Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
OpenGL ES does not support implicit type cast. Add explicit type cast for obs_load_* functions that are hardcoded. Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Add another copy of glad for OpenGL ES usage. Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
This patch adds a CMake option called "USE_GLES", and codepaths for OpenGL ES compatibility. The glad loader is switched to another copy for GLES when this option is on. One plugin that will load OpenGL is also slightly changed to load GLES instead of GL. Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
I don't think we have any interest in supporting these kinds of platforms. |
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. |
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.
Would EGL+GLES be any better there? But we intend to move to Vulkan anyway.
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. |
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?
Types of changes
Checklist: