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.