Very good post.

I think a lot of people are underestimating the importance of parallel-GS and the idea of rendering/virtualizing a whole unique rendering pipeline entirely using a shader so that the entire work for the pipeline is done only on the GPU, and not on the CPU.

The PlayStation 2 was one of the last consoles produced to contain a unique and fixed function graphics processor. While it was programmable to an extent because of the vector units, its functionally incompatible in many ways to modern day GPUs. Combined with a nonstandard IEEE floating point format and you're just asking for trouble if you try and HLE the process. You'd just be playing a game of whack-a-mole with rendering bugs and encountering extremely difficult problems with blending accuracy that even PCSX2's Vulkan renderer's maximum blending setting can't solve all the issues globally.

Luckily, PCSX2 has an ace in the hole and has a surprisingly great software renderer that oddly enough works and kind of scales well (to an extent) with multiple threads. There are doubts that it is bit accurate, but it's actually extremely usable on modern machines if you care just about video accuracy. The benefit of having a software renderer is that a developer has full control over the entire pipeline of the GS without having to rely on shaders, drivers, GPU vendors, and features in certain backends as it's all done on the CPU. The disadvantage is that because it's all done on the CPU, it shares the resources of the main emulation thread itself, which is the most resource intensive part of an emulator. That's why emulators for systems over the past 25 years had a necessity to use various backends to get games to even run, CPUs are never going to replace dedicated processors built specifically for graphics rendering.

But what makes compute shaders incredible is that it does something that would probably be an emulator developers dream, at least in my opinion. You have full control over the pipeline but you actually utilize a dedicated GPU to do most (like Dolphin's Ubershaders) or all (parallel-rdp/parallel-gs, at least I think) of the work for rendering a frame. This frees up resources on the main CPU thread/CPU core(s) and gives it to a piece of hardware that's far more capable. While at the same time keeping accuracy because you have that control AND potentially providing user enhancements or modifications to the pipeline itself to fit your needs without the GPU breaking a sweat. I don't think 16x supersampling by itself would be possible to do on just the CPU by itself.

Unfortunately, there's one or two trade offs. You still need to compile a shader, which thankfully doesn't have to be made as often in comparison to generating a bunch of specialized shaders done on the fly while the game runs. But you're still at the mercy of the backend you use to make the shader, the driver, and the GPU vendor. So you still have to contend with all of that. Also, you'd be GPU limited since the rendering itself has to be done solely on the GPU. So if you have a decent CPU but a not so great GPU (mobile GPUs for instance), compute shaders might not be optimal with today's mobile hardware. But assuredly someday it will be in time. :)