Bug 223637 – Use system's OpenGL ES directly when WebGL is disabled

• Status: NEW
• Component: Platform

[Don Olmstead]

ANGLE provides OpenGL ES 2/3 over OpenGL/Metal/OpenGL ES/Vulkan. When there's already a system OpenGL ES 2/3 it only makes sense to use ANGLE if WebGL validation is required. Otherwise it should go straight to the system OpenGL ES 2/3.

Ideally we should be able to collapse the OpenGL rendering class hierarchy by assuming we always have an OpenGL ES 2/3 implementation present.

[Kimmo Kinnunen]

Can you rephrase? The title and the description do not match in my reading.
This is filed in webgl. I don’t think it is feasible to envision webgl without angle.

For non-Mac compositors, they should work with whatever abstraction needed. Preferably this would not be GraphicsContextGL, as that would mean it would be hard to change GraphicsContextGL.

[Kenneth Russell]

Keep in mind that ANGLE provides uniform, consistent and conformant OpenGL ES semantics even when hosted on top of OpenGL ES itself. It papers over dozens if not hundreds of driver bugs found on various platforms, and can add value even if not used directly for WebGL.

[Radar WebKit Bug Importer]

<rdar://problem/76004873>

[Don Olmstead]

(In reply to Kenneth Russell from comment #2)
> Keep in mind that ANGLE provides uniform, consistent and conformant OpenGL
> ES semantics even when hosted on top of OpenGL ES itself. It papers over
> dozens if not hundreds of driver bugs found on various platforms, and can
> add value even if not used directly for WebGL.

I'm not trying to detract from the amazing work the folks working on ANGLE have done over the years. I do understand the benefits of using ANGLE as an OpenGL ES implementation.

Our situation is that we have an embedded device with a home grown OpenGL ES implementation. On PlayStation 5 we don't support WebGL and don't have plans to. On PlayStation 4 we have a handful of legacy apps that use WebGL 1 but we do not expose WebGL to the world at large.

This puts us into a position where ANGLE, even its compiler, is just pure overhead.

So I envision the following for when ANGLE is used in WebKit

Apple - Always USE_ANGLE
Desktop GL - Always USE_ANGLE
OpenGL ES - USE_ANGLE only if ENABLE_WEBGL (unless explicitly told not to USE_ANGLE *means can't do WebGL 2*)

This means we can collapse things down in platform so there's always an OpenGL ES implementation that's either provided by ANGLE or the system.

That make more sense? I can try and elaborate more. Also I can change the component if you all don't think this is WebGL. Maybe just platform or ANGLE.

[Kimmo Kinnunen]

> This puts us into a position where ANGLE, even its compiler, is just pure overhead.
> This means we can collapse things down in platform so there's always an OpenGL ES implementation that's either provided by ANGLE or the system.

I think you're still not explicitly mentioning *for what* you talk about using the OpenGL ES for. But if I understand your proposal correctly, yes, feel free to do whatever you want :)

So like I said:
I see the only realistic scenario that the WebGL implementation is implemented on top of ANGLE.

For any other graphical functionality, be it compositing, painting/rasterizing, whatever, the ports should of course be free to implement whatever they need and that only. However, maybe you should change the component for this bug from WebGL to something else. If WebGL implementation is then blocking you achieve your goal, you can perhaps file blocking bugs for the individual cases against WebGL (and fix those :) )

Which flags are on by default is, as far as I understand, port-specific decisions.

[Kenneth Russell]

Changing summary per discussion with Don to clarify the intent.

[Kenneth Russell]

(In reply to Don Olmstead from comment #4)
> Our situation is that we have an embedded device with a home grown OpenGL ES
> implementation. On PlayStation 5 we don't support WebGL and don't have plans
> to.

:( While of course it isn't close to the primary use case for the PlayStation platform, it would be really nice if the PS5's web browser would support WebGL. Given the experience our team's gathered from sandboxing and validating WebGL, this seems achievable from the technical side.

> On PlayStation 4 we have a handful of legacy apps that use WebGL 1 but
> we do not expose WebGL to the world at large.
> 
> This puts us into a position where ANGLE, even its compiler, is just pure
> overhead.

OK, understood.

> So I envision the following for when ANGLE is used in WebKit
> 
> Apple - Always USE_ANGLE
> Desktop GL - Always USE_ANGLE
> OpenGL ES - USE_ANGLE only if ENABLE_WEBGL (unless explicitly told not to
> USE_ANGLE *means can't do WebGL 2*)

Understood and agreed on all of these, except I don't understand the "unless explicitly told not to USE_ANGLE *means can't do WebGL 2*" parenthetical comment. Could you rephrase this?

USE_ANGLE on top of OpenGL ES 3.0 certainly supports WebGL 2. That's the configuration that has been enabled on iOS builds for several months now. WebGL 2 context creation will fail at runtime if OpenGL ES 3.0 isn't supported, for example on OpenGL ES 2.0-only devices.

> This means we can collapse things down in platform so there's always an
> OpenGL ES implementation that's either provided by ANGLE or the system.
> 
> That make more sense? I can try and elaborate more. Also I can change the
> component if you all don't think this is WebGL. Maybe just platform or ANGLE.

Yes, makes sense modulo the question above.