GL4ES compatibility

[illwieckz]

I flag it as draft to make it obvious I'm not intending to merge this for the 0.56 release.

I'm just pushing it because it's somewhat usable and as Linus Torvalds said once:

Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it ;)

This implements some compatibility code path making possible to run the Dæmon engine and the Unvanquished game on OpenGL ES hardware using the GL4ES translation layer.

In fact this basically implements some compatibility code path for GL ES 2 (what currently targets GL4ES) for when GL4ES isn't able to translate OpenGL to GL ES because of GL ES limitation.

The purpose of this is to allow me to test the engine on more hardware. I used this to confirm the bug we observe on PowerVR-derivated hardware like Apple AGX/Moore Threads is indeed reproducible on PowerVR:

• PowerVR/Moore Threads/Apple AGX: missing geometry when the camera is perfectly aligned on axes #1892

The only Imagination-branded PowerVR device I own is soldered on a RISC-V board, and while there is a Vulkan Mesa driver being on development for it (purposed to be a backend for the Mesa zink OpenGL translation layer), the RISC-V architecture of the said board is very new and then the whole Linux support is experimental and so getting the game running on GL4ES is far less work than doing platform-enablement at the whole distro level. So that allows me to use the proprietary OpenGL ES Imagination driver for PowerVR which is bundled with the distro provided for the board (the Proprietary Imagination Vulkan driver isn't featureful enough to run Zink). I even don't have to rebuild neither the kernel, neither Mesa!

This also brings more rewrite of existing compatibility code in a better way.

I started to implement ways to detect the underlying hardware when running API translators, this may be extended to things like VirGL, Zink or Parallels in the future.

GL4ES actually added such wanted feature on my request:

• [Feature request] Disclosing a bit of the underlying technology (driver, hardware…) ptitSeb/gl4es#502

I have more ideas for some rework on the driver/hardware detection (especially moving things like TRANSLATOR to a different variable than HARDWARE).

So this doesn't only benefit GL4ES and PowerVR.

[illwieckz]

On a side note, as recently discussed on the Chat, this may help us to port the game to Android.

There are three kinds of requirements for Android:

• Build support, figured out (patches unmerged, but they do exist, we can already run a server with those patches)
• NaCl support (work in progress) or Wasm.
• GLES (directly or through GL4ES, this) or Vulkan (work in progress) when Vulkan is available.

This assuming a Linux-like environment on Android, like Termux. Direct Android integration would require more work.

[illwieckz]

Not something critical, but it makes it easy for me to test hardware before Desktop OpenGL is implemented. It is very common on non-x86 platforms that hardware ships with only a GLES driver, but then we may want to test the hardware. An example of such hardware testing was to compare macOS OpenGL on AGX and Linux proprietary Imagination GL ES driver on PowerVR, to confirm that a bug is shared and may be a design bug.

This also introduces some framework to detect underlyings driver behind translation layers. This can be extended in the future to detect other underlying drivers, like detecting the macOS driver hiding behind Parallels, or the Linux driver hiding behind VirGL or Zink, and other things like that.

[illwieckz]

I rebased it over (which already included code from this):

• Detect Zhaoxin GPU, disable realtime lighting on it #1968

Even if this is less needed for the players, merging it makes my work easier not only because of the testing of drivers and hardware, but also because it improves the generic detection & workaround framework, and that is used in newer code outside this PR.

And in the meantime this generic detection & workaround framework was also modified by those other PRs in parallel and brought annoying merge conflicts when rebasing over those other PRs:

• Detect Zhaoxin GPU, disable realtime lighting on it #1968
• Respect GL_MAX_UNIFORM_BLOCK_SIZE for dlights buffer #1969

Including some commits in #1968 reduced the merge conflicts, but there was others and I already had to fix them many times… First #1968 conflicted with #1902 (this one) so I included some in #1968, but then #1968 conflicted with #1969 and I had to solve conflicts while rebasing, and then #1902 (this one) conflicted back with #1968, and I had to solve conflicts while rebasing again, etc. It's a pain loop. 🔄️😵️😁️

[illwieckz]

So, even if less needed, I would appreciate a lot to merge this.

[slipher]

For the smoothstep thing, I think it would be simpler and more robust to do it like, if GLSL 120 is used,

#define smoothstep mysmoothstep
float mysmoothstep(...) { /* our implementation */ }

Then the success condition is, we provide an implementation OR the driver provides an implementation. Not we provide an implementation XOR the driver provides one. No workaround would be needed.

[illwieckz]

For the smoothstep thing, I think it would be simpler and more robust to do it like, if GLSL 120 is used,

#define smoothstep mysmoothstep
float mysmoothstep(...) { /* our implementation */ }

Then the success condition is, we provide an implementation OR the driver provides an implementation. Not we provide an implementation XOR the driver provides one. No workaround would be needed.

The driver always overrides defines?

[illwieckz]

@slipher what do you think about my fixup-smoothstep commit?

[slipher]

@slipher what do you think about my fixup-smoothstep commit?

I don't understand how __VERSION__ is expected to be evaluated. Is that supposed to be evaluated to the fake GLSL version by the translation layer, or to the GLSL ES version by the final GLES driver?

[illwieckz]

@slipher what do you think about my fixup-smoothstep commit?

I don't understand how __VERSION__ is expected to be evaluated. Is that supposed to be evaluated to the fake GLSL version by the translation layer, or to the GLSL ES version by the final GLES driver?

Hmm, good question, probably the translation layer aka GL4ES here. So maybe we should just do the test in C++ and in GLSL.

[illwieckz]

I reimplemented the glConfig.shadingLanguageVersion <= 120 test.

[slipher]

Looking at the GL4ES readme/issues, there are various required features missing for our renderer. Like
no 3D textures, no sRGB textures, no reading from the depth texture (required for depth fade and fog), and
no occlusion queries. It's far from being a usable backend for players. So if you really want to test with
this for some reason, how about disabling deform shaders? As there are lots of other things that will be even
more broken. IIRC deform shaders are the only use case of linking multiple shaders of the same type,
so all that ugly code for concatenating vertex shaders could be dropped.