renderer: detect if hardware cannot blend RGBA16 framebuffers

[illwieckz]

Use GL_ARB_internalformat_query to check if the hardware cannot blend GL_RGBA16 framebuffers.

Hardware like ATI R300 support RGBA16 framebuffers but can't blend them. The check should detect them.

Unfortunately the Mesa r300 driver has a bug and wrongly reports such blending to be possible despite the hardware not supporting it, but since we already detect R300 hardware we can also workaround that so a workaround was also implemented.

A fix is on the way on Mesa side.

See this thread for details:

• https://gitlab.freedesktop.org/mesa/mesa/-/issues/11669

See also this is work-in-progress merge-request on Mesa side:

• https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30612

The extension to check for the feature availability is much more recent than the feature itself:

• https://registry.khronos.org/OpenGL/extensions/ARB/ARB_internalformat_query.txt

So if it is not possible to check for the feature availability, the engine assumes the feature is available.

The purpose is to not use the feature if the driver explicitly says the feature is not supported or if we know the feature is not supported. In case the assumption is wrong and r_highPrecisionRendering is enabled, the symptom is translucent textures being rendered opaque, as seen in #1232:

• https://github.com/DaemonEngine/Daemon/issues/1232

Fixes #1232.

[illwieckz]

This also fixes a bug where GL_RGBA16 textures were wrongly tested in float-related code and then wrongly assumed to be unavailable when float textures were not.

[ondracka]

BTW might be better to actually require GL_ARB_internalformat_query2. There the GL_FRAMEBUFFER_BLEND is actually defined, while in GL_ARB_internalformat_query this is not required and is only mentioned in the QA section...

[illwieckz]

A discrepancy in OpenGL documentation was discovered:

If pname is GL_FRAMEBUFFER_BLEND, params is set to GL_TRUE to indicate that the internal format is supported for blending operations when attached to a framebuffer, and to GL_FALSE otherwise.
-- https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGetInternalformat.xhtml

FRAMEBUFFER_BLEND: The support for rendering to the resource via framebuffer attachment when blending is enabled is returned in params. Possible values returned are FULL_SUPPORT, CAVEAT_SUPPORT, or NONE. If the resource is unsupported, NONE is returned.
-- https://registry.khronos.org/OpenGL/extensions/ARB/ARB_internalformat_query2.txt

And and unfortunately GL_FULL_SUPPORT (33463) is not GL_TRUE (1).

[illwieckz]

The code now tests for GL_FULL_SUPPORT or GL_TRUE for enablement (in case different drivers based their implementation on this or that document), but only what is not GL_FULL_SUPPORT or GL_TRUE is considered to be trusted as a feature disablement.

I still believe it's a good idea to use internalFormatQuery2 because it means that once Mesa is fixed the workaround to detect the missing feature will not be used on R300 (the hardware known to not support the feature). With the help of the upcoming workaround branch providing toggles to disable workarounds, the Dæmon engine/Unvanquished game would be more usable as a testbed for OpenGL compatibility and for reporting issues against upstream drivers, something I find very good: it's always good when our software is considered as a reference for benchmarking/testing and used as such.