[3.x] Add optional ANGLE support for Windows desktop.

[EIREXE]

This commits adds an optional support for ANGLE in 3.2, this can be used by placing the angle source tree at thirdparty/angle, building it in release mode (with out/Release as the output) and using the use_angle=yes option when building.

The rationale behind this is that usage of ANGLE (particularly with the vulkan backend) gives a considerable performance boost on Windows in most cases, and in some cases (NVIDIA Optimus for example) might even stabilize frametimes and make games playable that weren't before.

The likely reason behind this is that OpenGL drivers on windows are just in a very bad shape, from my own experimentation my game gets an over 300-400 FPS boost (up from ~200) during gameplay, and many users (again, particularly those on mobile platforms) have reported very big improvements in speed and frametime.

The code has been written in such a way that it will try to fallback through different backends, in order:

• Vulkan
• D3D11
• OpenGL

This is done unless the --angle-backend paremeter is specified.

In my opinion this is a very important for those games that will remain on 3.2 and might never jump to 4.0.

Many OpenGL games (and software) use ANGLE in production successfully (see https://en.wikipedia.org/wiki/ANGLE_(software)#Software_utilizing_ANGLE).

The reason why this commit is done against the 3.2 branch specifically is because it's unecessary in 4.0, as that already runs on Vulkan natively.

This effort was started by me, with some improvements done by @fire , I finished the job by making it fully optional.

Happy new year!

Bugsquad edit: This closes godotengine/godot-proposals#1725.

[EIREXE]

I've discovered that in my game creating imagetextures from disk with mipmaps or filtering enabled results in a black texture, I believe this is as a result of some non-standard thing godot is doing as I encountered this issue when porting godot to an obscure platform, this is backend and internal GLES version dependent. This is not a concern for most games since loading built (from res://) textures works fine and it might be a result of known threaded loading issues anyways, but it's something I think I should document too.

This also happens in the existing UWP port.

[lawnjelly]

Plus one from me, as I'm a big fan of using wrappers like this to deal with platform / driver issues. This also could potentially be very helpful on Mac when Metal support is completed for Angle, as GL support on Macs has been problematic.

I suspect this has been discussed before I started contributing, I don't know what the policy is on this. I wonder how big the dependencies are in terms of compiling, binary size etc. And of course any impact in terms of support issues.

[fire]

‘’’cpp
vec3 GET_LIGHT_POSITION(LightData ld) {
return ld.light_pos_inv_radius.xyz;
}
‘‘’

some code was mistakenly added.

The glsl compliance and precision changes are needed but the uppercase shaders aren’t

[EIREXE]

Plus one from me, as I'm a big fan of using wrappers like this to deal with platform / driver issues. This also could potentially be very helpful on Mac when Metal support is completed for Angle, as GL support on Macs has been problematic.

I suspect this has been discussed before I started contributing, I don't know what the policy is on this. I wonder how big the dependencies are in terms of compiling, binary size etc. And of course any impact in terms of support issues.

The reason why this is done as an optional thing is because compiling angle is a PITA, so you can still compile using desktop GLES3.

[reduz]

Afaik shader compilation in Angle is very slow. How does this work compared to native?

[EIREXE]

Afaik shader compilation in Angle is very slow. How does this work compared to native?

I am actually not sure if it's that slow, from my naive testing on a very old tablet (one equipped with an intel N4100) it seems to run smoother than native OpenGL, even with some particles.

I don't make heavy use of particles but I have to say it doesn't feel any worse than native.

[himaghnam]

Can anyone post a link to compiled angle

[hpvb]

I think it would be nice if we do this to put angle in thirdparty/ and add some detection to determine whether to use Angle or not at runtime on Windows builds (including a command-line switch). I don't think it makes sense to merge this in this state personally.

What I mean specifically is this: We always have Angle support in official builds. use_angle=yes is the default, and built from thirdparty. We add some heuristics like we have for X11 for PRIME detection to determine when it makes sense to use Angle or not. If we can't use it by default I don't think we should merge it into 3.2 primarily because it won't get tested enough for us to support, and most people most of the time won't be able to use it as most people don't build the engine.

[EIREXE]

I think it would be nice if we do this to put angle in thirdparty/ and add some detection to determine whether to use Angle or not at runtime on Windows builds (including a command-line switch). I don't think it makes sense to merge this in this state personally.

What I mean specifically is this: We always have Angle support in official builds. use_angle=yes is the default, and built from thirdparty. We add some heuristics like we have for X11 for PRIME detection to determine when it makes sense to use Angle or not. If we can't use it by default I don't think we should merge it into 3.2 primarily because it won't get tested enough for us to support, and most people most of the time won't be able to use it as most people don't build the engine.

The problem is building angle, unfortunately I have no idea how to build angle without google's toolchain.

[hpvb]

The problem is building angle, unfortunately I have no idea how to build angle without google's toolchain.

If this idea is accepted I will make that work.

[hpvb]

As an aside: Mesa just merged a GL over D3D12 driver, paid for by Microsoft. An alternative to ANGLE could be vendoring mesa with that driver.

[GeorgeS2019]

@hpvb It seems Microsoft OpenGL strategy is to replace all Angle to Mesa3D, especially for making OpenGL to work in SurfaceX and WSL2

We need to make more aware of that, by sharing this to Godot UWP developers that depends on Angle NOW

[EIREXE]

@hpvb It seems Microsoft OpenGL strategy is to replace all Angle to Mesa3D, especially for making OpenGL to work in SurfaceX and WSL2

We need to make more aware of that, by sharing this to Godot UWP developers that depends on Angle NOW

Doesn't the mesa driver translate to DX12? DX11 compatibility is better in our use case IMO because the big issues only happen in less powerful hardware. Then against most modern variations of those use dx12...

[UnderSampled]

When I used Angle before, I had a specific need for DirectX<->OpenGLES crossover, but I ultimately found that it was actually more stable and standards compliant, and maybe even more performant than the OpenGLES implementation provided by the native graphics drivers. That's actually the reason ANGLE exists -- Google determined that support for ES on desktops was very limited, and they needed it to be stable enough for WebGL. Mozilla agreed, and is using ANGLE as well for Firefox. I guess Microsoft now also uses it in Edge (being Chromium). Being the same implementation that's used for WebGL, it makes sense that it would be easier to support tandem WebGL development. It also has an implementation of EGL, so it actually requires less windows specific code to use.

Regardless of if Mesa3D also supports a DirectX based driver, I don't see this reducing how well supported ANGLE's version is.

Anyways, my thoughts are positive regarding ANGLE, and I heartily agree that Godot should use it for it's OpenGLES implementation for Windows in general.

[Calinou]

That's actually the reason ANGLE exists -- Google determined that support for ES on desktops was very limited, and they needed it to be stable enough for WebGL. Mozilla agreed, and is using ANGLE as well for Firefox. I guess Microsoft now also uses it in Edge (being Chromium).

On the other hand, many of the issues that people have run into with WebGL 2.0 on Windows are caused by ANGLE. These issues disappear if you force the browser to use native OpenGL.

Due to this, I wouldn't use ANGLE by default. Instead, it should only be enabled on known problematic GPUs in a way similar to godotengine/godot-proposals#1609.

[norrath-hero-cn]

This is cool if this PR is cooperate with the #50253 PR to make a new PR that make Godot transparently use vulkan, metal, d3d backends through an "abstract layer"(gles 3/2)

if 3.x gonna be a LTS version this kind of "cross backends" abilities are very useful, and more compatible

[Gnumaru]

I tryed to compile @EIREXE's fork of godot at "https://github.com/EIRTeam/godot", but after compiling and running it displays a messagebox with the error "Your video card driver does not support any of the supported OpenGL versions. Please update your drivers or if you have a very old or integrated GPU, upgrade it.".

This messagebox is triggered at platform/windows/os_windows.cpp:1600 when gl_initialization_error is false.

These are roughly the steps I did to compile angle and @EIREXE's fork of godot:

set DEPOT_TOOLS_WIN_TOOLCHAIN=0

set PATH=%CD%\depot_tools;%PATH%

git clone --recursive https://chromium.googlesource.com/chromium/tools/depot_tools.git

gclient sync

git clone --recursive https://github.com/EIRTeam/godot.git godot_eirteam

cd godot_eirteam/thirdparty

git clone -b main --recursive https://github.com/google/angle.git

cd angle

python scripts/bootstrap.py

gclient sync

gn gen out/Release --args="is_debug=false"

autoninja -C out/Release

cd ..\..\

scons -j5 p=windows vsproj=yes use_angle=yes

xcopy thirdparty\angle\out\Release\libEGL.dll .\bin\

xcopy thirdparty\angle\out\Release\libGLESv2.dll .\bin\

.\bin\godot.windows.tools.64.ANGLE.exe

But as I said, even though it compiles and links successfully, it fails on creating a valid gl context.

Also, I noticed there was a typo on "platform/windows/context_gl_windows_angle.cpp" that prevents compilation. On line 315, where it's written if (contecontext_offscreenxt == EGL_NO_CONTEXT) {, it should be if (context_offscreen == EGL_NO_CONTEXT) {.

[EIREXE]

I tryed to compile @EIREXE's fork of godot at "https://github.com/EIRTeam/godot", but after compiling and running it displays a messagebox with the error "Your video card driver does not support any of the supported OpenGL versions. Please update your drivers or if you have a very old or integrated GPU, upgrade it.".

This messagebox is triggered at platform/windows/os_windows.cpp:1600 when gl_initialization_error is false.

These are roughly the steps I did to compile angle and @EIREXE's fork of godot:

set DEPOT_TOOLS_WIN_TOOLCHAIN=0

set PATH=%CD%\depot_tools;%PATH%

git clone --recursive https://chromium.googlesource.com/chromium/tools/depot_tools.git

gclient sync

git clone --recursive https://github.com/EIRTeam/godot.git godot_eirteam

cd godot_eirteam/thirdparty

git clone -b main --recursive https://github.com/google/angle.git

cd angle

python scripts/bootstrap.py

gclient sync

gn gen out/Release --args="is_debug=false"

autoninja -C out/Release

cd ..\..\

scons -j5 p=windows vsproj=yes use_angle=yes

xcopy thirdparty\angle\out\Release\libEGL.dll .\bin\

xcopy thirdparty\angle\out\Release\libGLESv2.dll .\bin\

.\bin\godot.windows.tools.64.ANGLE.exe

But as I said, even though it compiles and links successfully, it fails on creating a valid gl context.

Also, I noticed there was a typo on "platform/windows/context_gl_windows_angle.cpp" that prevents compilation. On line 315, where it's written if (contecontext_offscreenxt == EGL_NO_CONTEXT) {, it should be if (context_offscreen == EGL_NO_CONTEXT) {.

You are probably missing vulkan-1.dll, try the dx11 backend and see if it works with --angle-backend d3d11

[Gnumaru]

You're right, I was missing vulkan-1.dll. I didn't know I needed it, since running without libEGL.dll or libGLESv2.dll gave me a windows dynamic linking error (so godot's main() probably never even started), but without vulkan-1.dll godot launched correctly up to the point of trying (and failing) to create a gl context.

Indeed, running godot with "--angle-backend d3d11" allowed me to run even without angle's vulkan-1.dll. I did not pay attention at the part you mentioned the "--angle-backend" command line flag =P.

[Gnumaru]

I have noted that the "--angle-backend" cli parameter does not "propagate". For example, when starting the project manager with --angle-backend d3d11, after chosing a project, it will ignore the cli param and start with the vulkan backend. And if you start the editor directly, uppon playing a scene, the scene will play with the vulkan backend, also ignoring the cli param.

Also interesting to notice that by testing a scene of my (2d) game using all three backends, on an nvidia gpu, opengl gave me the highest fps, whereas d3d11 gave the worst fps. But even angle's opengl backend gave me about one quarter of the fps I get with the oficial godot build =S

[EIREXE]

I have noted that the "--angle-backend" cli parameter does not "propagate". For example, when starting the project manager with --angle-backend d3d11, after chosing a project, it will ignore the cli param and start with the vulkan backend. And if you start the editor directly, uppon playing a scene, the scene will play with the vulkan backend, also ignoring the cli param.

Also interesting to notice that by testing a scene of my (2d) game using all three backends, on an nvidia gpu, opengl gave me the highest fps, whereas d3d11 gave the worst fps. But even angle's opengl backend gave me about one quarter of the fps I get with the oficial godot build =S

I suppose it's hardware dependant, on hardware with terrible opengl support I've seen ANGLE vulkan surpass it, but it's still not faster than mesa

[akien-mga]

Just a quick status update after discussing this in a PR review meeting:

• We like the idea to use ANGLE for more platforms to work around old/bad OpenGL drivers.
• We'd prefer to focus on how to do this well for 4.x, i.e. once the OpenGL3 renderer has been reimplemented and we can start looking into how to hook things with ANGLE (notably the whole buildsystem issue which won't be trivial).
• Then we can look into doing the same for 3.x if there's demand, possibly for 3.6+ (likely opt-in since the OpenGL drivers, despite their flaws, are more battle tested now for our renderer implementation in 3.x).

[EIREXE]

Just a quick status update after discussing this in a PR review meeting:

* We like the idea to use ANGLE for more platforms to work around old/bad OpenGL drivers.

* We'd prefer to focus on how to do this well for 4.x, i.e. once the OpenGL3 renderer has been reimplemented and we can start looking into how to hook things with ANGLE (notably the whole buildsystem issue which won't be trivial).

* Then we can look into doing the same for `3.x` if there's demand, possibly for 3.6+ (likely opt-in since the OpenGL drivers, despite their flaws, are more battle tested now for our renderer implementation in 3.x).

I think there's a lot more work than anticipated, my game was quite simple, but introducting stuff like a multimeshinstance2d doesn't appear to work yet on ANGLE, I wonder why.