[macOS / Windows] Add optional ANGLE support.

[bruvzg]

A new version of #54914

Pre-build ANGLE libraries are required, build it from source or get from the CEF minimal distribution. Headers are included.

---

To test it with upstream ANGLE:

• Build Godot with additional options:

    opengl_implementation=angle extra_suffix=angle

• Copy libEGL.dylib and libGLESv2.dylib to the .app bundle Frameworks folder (macOS).
• Copy libEGL.dll and libGLESv2.dll to the executable folder (Windows).

---

ANGLE platform type can be selected by running Godot with --angle-platform-type type command line argument.

• On macOS, valid type values are: metal (default) and opengl.
• On Windows, valid type values are: d3d11 (default), vulkan, and opengl.

[Riteo]

Mh, I'm not sure, but this looks like this works with EGL? I'm not sure if ANGLE magic is changing things up. Couldn't this be based somehow on #68944? If there's no magic behind the scenes we could avoid having multiple EGL manager implementations floating around when the time comes.

I guess that, with that PR, there could be two derived EGL managers: EGLManagerMetalANGLE and EGLManagerANGLE, each one having a different platform string. That sounds a lot but it'd be just two dumb static methods returning a constant value per manager. Then the DisplayServer could attempt initializing either and there could be the fallbacking based on the result, I guess.

I also recall @clayjohn trying to do ANGLE stuff with my generic EGLManager driver, wonder what came from that.

I'm curious on what's possible and I'd be glad to help, but I know nothing about Apple developoment so I might be ignoring important stuff.

[bruvzg]

Mh, I'm not sure, but this looks like this works with EGL? I'm not sure if ANGLE magic is changing things up. Couldn't this be based somehow on #68944? If there's no magic behind the scenes we could avoid having multiple EGL manager implementations floating around when the time comes.

Apart for a few extra attributes for the display creation and two Objective-C lines which can be moved to the DisplayServer, it should be generic EGL, so I guess it can use the same GLManager. I'm not sure about GLAD (it does not support ANGLE platform extensions, but it's probably only a few enums), I'll check it out.

[bruvzg]

Couldn't this be based somehow on #68944?

Updated to use common EGL manager based on #68944 and GLAD (dylibs are no longer necessary to build Godot, only to run with GL renderer). Since it's using GLES not GL I have added a few extra virtual methods to the EGL manager to configure API type and arguments for display and context.

GL/GLES defines and includes will need a bit of cleanup, it's a mess right now.

[Riteo]

@bruvzg

Updated to use common EGL manager based on #68944 and GLAD (dylibs are no longer necessary to build Godot, only to run with GL renderer).

Great!

Since it's using GLES not GL I have added a few extra virtual methods to the EGL manager to configure API type and arguments for display and context.

I saw the diff and those methods seem to make sense, great job! I'm glad that the driver's API is good enough even for this funky library.

GL/GLES defines and includes will need a bit of cleanup, it's a mess right now.

Yeah, I noticed that too. There's also some GLAD-related stuff that isn't confined in its own defines.

[bruvzg]

Added EGL_ANDROID_blob_cache caching to mitigate slow ANGLE shader conversion, now it starts instantly on the subsequent runs.

[clayjohn]

As a note, our original plan for ANGLE was to utilize it as an optional driver (like how you will be able to select between Vulkan and D3D12). How difficult do you think it would be to make angle/non-angle selectable in the project settings instead of making it a compile time option?

godotengine/godot-proposals#4261

[bruvzg]

How difficult do you think it would be to make angle/non-angle selectable in the project settings instead of making it a compile time option?

Got it working on macOS, so it is possible. Need a lot of cleanup, and some extra work to make sure it is working on mobile and web, since these do no use GLAD. Also, I have not touched OpenXR stuff at all. But here's a draft branch:

https://github.com/bruvzg/godot/tree/angle%2B%2B

An --rendering-driver opengl3_angle / --rendering-driver opengl3 argument can be used to select ANGLE or native GL. It's currently not exposed to UI/project settings. Maybe it should use rendering_method = gl_native / gl_angle instead of renderer name?

[bruvzg]

Superseded by #72831