Future hardware renderer

[ssk97]

This is a bit preemptive, but I figure it'll be good to have somewhere to discuss the hardware renderer we'll need at some point in the future.

My take on the options: 1) Full Translation- similar to PCSX2, convert everything to modern GPU commands/formats. -Pros: By far the best GPU utilization easiest to make hacks/enhancements -Cons: Some effects can't be easily done likely requires the most hacks to get working

2) Soft Hardware/Compute Shaders- Basically just do software rendering but massively parallel and on the GPU -Pros: As accurate as Software Rendering Code will more closely match the software renderer CPU should do very minimal work Driver bugs likely don't matter -Cons: Extremely slow- ~5x slower than normal, possibly even worse Older GPUs can't be used at all

3) Hybrid- Use the hardware rasterizer, but keep as much as possible in PS2 formatting -Pros: CPU should do less work -Cons: Incredible complexity May need to convert back from modern framebuffer to PS2 format more frequently Slower than Full Translation

In addition, we have to choose which API we'll be using: 1) OpenGL- works everywhere, but drivers can be bad. MacOS does not support 4.3 and thus doesn't have Compute Shaders 2) Vulkan- MacOS does not have support except via MoltenVK. Even worse drivers on many mobile platforms. Older mobile platforms don't have any support 3) Direct X- Windows only, so probably not 4) Molten- MaxOS/iOS only, so probably not 5) Do it Yourself- HAHA yeah no.

I'm personally thinking Compute Shaders+Vulkan is a good choice, but the speed cost is significant and requiring MoltenVK for Mac/iOS is annoying. It will also be harder to support enhancements (particularly increased resolution).

[ssk97]

Giving a small update- after some rough guesses, the compute shader solution is unlikely to be fast enough to work on mobile devices. As such, full translation seems like the best solution given that Android is meant to be a priority.

[Degerz]

I can't remember correctly but I'm pretty sure the creator of this emulator did not intended to have hacks integrated into it. I think he wanted to design this project in a similar vein to Dolphin where the code was maintainable and adding in a bunch of hacks would run counterproductive to that goal so don't shy away too early from using compute shaders considering the overall likely timespan of this project where Android graphics hardware will inevitably get more powerful in the not too distant future.

Avoid OpenGL as much as possible especially if you and the creator do plan on having an Android version since many hardware vendors are absolutely not interested in improving the standard. You will very likely screw yourself on that path if you ever need new/recent hardware features because hardware vendors are far less motivated to expose API support for new extensions on a dated and complicated API like OpenGL. There's also two different designs too such as OpenGL for desktop and OpenGL ES for mobile with the former being shoddy as it is on several OS/GPU combinations and the latter being too cruel of a joke from what I've heard. OpenGL hasn't had a major update to it's spec in a year so far with the last major update taking around 3 years to come out after the previous version released and OpenGL ES is going even stronger with not having updated for over 3 years in a row so far. OpenGL basically has no future in terms of portability, driver quality, development of new features and worst of all support in general from various hardware vendors all around since it's maintenance is consistently shunned. (if it's not Nvidia then it probably takes literal YEARS to sometimes fix a GL driver issue your encountering or support a feature you want)

[ghost]

Well, GPUs are very powerfull nowdays, I think the second option with the vulkan API would be the best.

[Degerz]

I imagine the release of the fragment shader interlock extension in Vulkan is going to make things a lot more worthwhile.

[phire]

can't remember correctly but I'm pretty sure the creator of this emulator did not intended to have hacks integrated into it. I think he wanted to design this project in a similar vein to Dolphin where the code was maintainable

Dolphin absolutely has hacks; Tonnes of them. What Dolphin shies away from is game specify hacks.

Regarding generic hacks, if the performance is good enough to do things the proper way, Dolphin's philosophy is to lean towards doing it the proper way. But if a less accurate method is needed for performance, then do it. Who cares if the emulator is accurate and has clean code if the user experience is poor.

[phire]

My recommendation would be to target somewhere between 1 and 2. But not quite 3.

Don't use compute shaders, you have triangles and software rasterization of triangles in compute shaders isn't that fast. Modern GPUs have fixed function that speed up the rendering of large batches of triangles.

So use the proper OpenGL/Vulkan graphics pipeline.

However, take full advantage of image load/store and fragment shader interlock (or a software fallback) to do software blending for full accuracy of tricky draw calls.
But I wouldn't hard code every draw call into using software rendering (well, it might be smart for an initial prototype). If a GS state can be accurately rendered with regular blending, you should be trying to do that, for performance.

I would personally avoid providing inaccurate fallbacks.
Take a hard stance that if the device doesn't support image load/store (opengl 4.2, es 3.2?) then you don't support hardware rendering on that device.

As for formatting, try and keep them in the host framebuffer format as much as possible. If a game is doing tricky things by abusing the ps2 framebuffer formats, use a re-interpretation shader to convert it from host native, to ps2, re-interpretation it as the new ps2 before writing it back the result the host native format. You should only be paying the cost when a game actually does a re-interpretation.

As for APIs, I'd recommend starting with a multi-API approach, simply to encourage development of a backend that cleanly separates the common code from the API specific code. The API specific code should be as thin as possible. In Dolphin, we spent a very long time trying to unify all the code out of the various backends into video common.

I'd recommend starting with opengl and vulkan as the initial APIs. Force OpenGL to look like vulkan as much as possible.
Having the ability to port to different APIs is useful, I could see you wanting to do a Metal backend, because Apple.

[Degerz]

Having the ability to port to different APIs is useful, I could see you wanting to do a Metal backend, because Apple.

Might as well have a D3D12 backend too since AMD doesn't want anybody touching interlocks on Vulkan even though their hardware clearly supports it as well ...