OpenGL renderer displays black screen under Mesa on Windows

[waddlesplash]

NOTE: Apparently the black screen also occurs under Mesa LLVMpipe without the ICD... guess I could have saved myself a lot of time by checking that first.

NOTE: GLon12 appears to still be "experimental technology", so it is entirely possible this bug is not mGBA's fault; I did not spend much time investigating. It is thus obviously low priority.

TL;DR

Mesa now has a D3D12 backend, and can be compiled as a system OpenGL driver for Windows; when using it, mGBA's OpenGL renderer or display mode show only a black screen. (Dolphin, and other applications that use OpenGL, work alright.)

Full explanation

Windows on ARM typically runs on devices that do not provide OpenGL drivers, so Microsoft has been working on a D3D12 backend for Mesa to provide OpenGL support. They have already released an early version of this in the Store, as the OpenGL Compatibility Pack.

While x64 builds are included, they do not override an existing OpenGL driver by default, so you have to manually edit the registry in order to actually use the driver. As far as I could tell, you cannot directly use the driver installed with the store package this way, since pasting in the "WindowsApps" installed path to the proper registry keys does not work. So, you have to download the package from the store manually:

1. Go to https://store.rg-adguard.net/
2. Paste in the address of the Compatibility Pack, as linked above.
3. In the dropdown on the right, choose "Fast".
4. Click the button, and download the "...x64...appx" file.
5. Extract the "x86" and "x64" directories somewhere (7-Zip works for this.)

Now the registry must be edited to force the use of this driver instead of your current one:

1. Open RegEdit and navigate to HKLM\System\CurrentControlSet\Control\Class\.
2. Search for a key called OpenGLDriverName. (NOTE: If you have more than one graphics card, more than one of the GUID folders will have a matching key; you may need to edit both.)
3. Save the current values of all the "OpenGL..." keys in the matching path.
4. Edit the OpenGLDriverName and OpenGLVendorName values to point to the x64\OpenGLOn12.dll extracted earlier. (NOTE: At least according to the official documentation on ICD loading, the first should be sufficient, but at least on my system, both were necessary...)
5. (Optional) Edit the OpenGL...WoW values to point to the x86\OpenGLOn12.dll for 32-bit applications.

At this point, 64-bit (and optionally 32-bit) applications should be using OpenGLOn12 as their OpenGL driver. You can validate this with a tool like OpenGL Extensions Viewer. You should then be able to reproduce the problem in mGBA.

[endrift]

So...what's your GPU?

[waddlesplash]

GPU 0

    Radeon RX 5500 XT

    Driver version: 27.20.14501.18003
    Driver date:    11/13/2020
    DirectX version:    12 (FL 12.1)

    Dedicated GPU memory    4.0 GB
    Shared GPU memory   16.0 GB

[kode54]

A reasonable course of action to use this on AMD cards, since their Windows OpenGL drivers just suck.

E: I take it back. This driver is considerably worse at heavy stuff. Minecraft with fancy shaders manages about 5fps here at 1080p. Maybe 10fps without any shaders.

[waddlesplash]

E: I take it back. This driver is considerably worse at heavy stuff. Minecraft with fancy shaders manages about 5fps here at 1080p. Maybe 10fps without any shaders.

Yes, it definitely has a ways to go. Zink has already surpassed it, and is probably better overall, but obtaining Windows builds of Zink was tricky until recently.

[waddlesplash]

So, it turns out, this actually reproduces with LLVMpipe using the stock "opengl32.dll", it is totally unrelated to using the ICD.