Skip to content
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

Closed
wants to merge 6 commits into from
Closed

RFC: OpenGL ES support #10977

wants to merge 6 commits into from

Conversation

Icenowy
Copy link

@Icenowy Icenowy commented Jul 13, 2024

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:

  • My code has been run through clang-format.
  • I have read the contributing document.
  • My code is not on the master branch.
  • The code has been tested.
  • All commit messages are properly formatted and commits squashed where appropriate.
  • I have included updates to all appropriate documentation.

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>
@derrod
Copy link
Member

derrod commented Jul 13, 2024

I don't think we have any interest in supporting these kinds of platforms.

@Icenowy
Copy link
Author

Icenowy commented Jul 13, 2024

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.

@kkartaltepe
Copy link
Collaborator

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.

@derrod
Copy link
Member

derrod commented Jul 13, 2024

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.

@WizardCM WizardCM added the New Feature New feature or plugin label Jul 13, 2024
@RytoEX
Copy link
Member

RytoEX commented Jul 31, 2024

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.

@RytoEX RytoEX closed this Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
New Feature New feature or plugin
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants