Written by rz5
From at least February to mid August there was a bug on beetle-psx’s GL renderer that only affected users with AMD GPUs.
This bug was exposed when user ‘orbea’ corrected a mistake in glsm (an OpenGL state manager, made by libretro, used in beetle-psx), where it would it would hint that beetle-psx wanted a version 3.1 core profile OpenGL rendering context but, by specification, the ‘core profile’ is only from version 3.2 onward.
It is still unknown why, but after orbea’s patch, AMD GPUs would render black frames on every situation except for FMVs.
Intel and Nvidia GPUs were unaffected.
Trying to find out what was wrong was very frustrating. CodeXL and RenderDoc were briefly used in the expectation that they would point out obvious API mistakes or perform API call order analysis and give a warning e.g. “are you sure you want to change this complex colored frame for a single-colored frame and present it?”
It is unfortunate that sometimes bugs like this pop up and due to the blackbox nature of closed-source proprietary drivers, using a debugger like gdb becomes unfruitful for hobby developers when you arive at the point where your opensource the code starts calling into driver code.
Then one begins to wonder: was it one of my commits in the past? Is our code going against the OpenGL spec in some way that triggers this behavior on the typically strict spec-following AMD drivers? Is it our fault at all?
And while this bug was active, users affected by it surely grew frustrated at the lack of progress and some even got dissuaded from using beetle-psx altogether.
Eventually, in mid August, update 18.8.1 came out for AMD’s Radeon Software graphics software and that seemingly fixed the bug. Which seems to indicate towards the problem being on the AMD driver side, not in beetle-psx.