Copy dependency for multisample and non-multisample textures

[gdkchan]

On the GPU, there are cases where we know that a texture is multisampled, and there are some cases that we don't know, the cases where we don't know, we have an overlap at the same address of a multisample texture, with a width and height that is equal to the multisample width and height multiplied by the amount of samples in X and Y respectively. Since multisample and non-multisample textures are not considered "compatible" in any API, most of those cases are not handled. Currently, there are a few tricks used to make some cases work. 2D engine blit source textures wil get multisample textures from the cache if it can find one at the requested address. Notably, the cases where a texture on the pool accessed from a shader does not have a multisample type on the texture descriptor is not handled right now, which causes problems on a few games using the Vulkan and OpenGL APIs on the Switch.

This change allows non-multisample texture at the same memory region as a multisample one to inherit the multisample texture data, rather than just reading garbage from memory. The main complication doing this is that APIs does not support doing pretty much anything with multisample textures other than rendering or accessing from shaders, so the solution I found here was using blits to "resolve" the multisample texture to a intermmediate texture, then upscale the intermmediate to the final texture. It should be fine if the intention is downscaling it later anyway, even if a bit inefficient. Another possible solution would be doing the copy with a compute shader, using images, but that has other issues too.

This change also allowed the case I added before to allow matching multisample <-> non-multisample textures with different but compatible formats to be removed. Since they are considered copy compatible now, the texture will still correctly inherit the data, but the old approach was slightly more efficient (it creates one view and does one copy, rather than creating a new copy dependant texture and doing one copy (it's actually 2 blits, as explained above) every time it is accessed after modification, plus the actual copy, so I can add it back if desired. I removed it mostly to make the code simpler and since only 1 game seems to trigger this case so far, and it doesn't do it enough for perf to be an issue.

This change fixes black screen on Perky Little Things.
Before:

After:

It also fixes the 3D sections on Genkai Tokki Moero Crystal H.
Before (from gamedb):

After:

It is still not rendering correctly due to another issue that is completely unrelated to this, so I will fix in another PR. But at least this change allows it to render at all.

I recommend testing this on games that uses multisampling, to ensure they did not regress.

[github-actions]

Download the artifacts for this pull request:

• ryujinx-Release-1.1.0+c4f8c0a-linux_x64
• ryujinx-Release-1.1.0+c4f8c0a-osx_x64
• ryujinx-Release-1.1.0+c4f8c0a-win_x64

Experimental GUI (Avalonia)

• ava-ryujinx-Release-1.1.0+c4f8c0a-linux_x64
• ava-ryujinx-Release-1.1.0+c4f8c0a-osx_x64
• ava-ryujinx-Release-1.1.0+c4f8c0a-win_x64

GUI-less (SDL2)

• sdl2-ryujinx-headless-Release-1.1.0+c4f8c0a-linux_x64
• sdl2-ryujinx-headless-Release-1.1.0+c4f8c0a-osx_x64
• sdl2-ryujinx-headless-Release-1.1.0+c4f8c0a-win_x64

Only for Developers

• ava-ryujinx-Debug-1.1.0+c4f8c0a-linux_x64
• ava-ryujinx-Debug-1.1.0+c4f8c0a-osx_x64
• ava-ryujinx-Debug-1.1.0+c4f8c0a-win_x64
• ryujinx-Debug-1.1.0+c4f8c0a-linux_x64
• ryujinx-Debug-1.1.0+c4f8c0a-osx_x64
• ryujinx-Debug-1.1.0+c4f8c0a-win_x64
• sdl2-ryujinx-headless-Debug-1.1.0+c4f8c0a-linux_x64
• sdl2-ryujinx-headless-Debug-1.1.0+c4f8c0a-osx_x64
• sdl2-ryujinx-headless-Debug-1.1.0+c4f8c0a-win_x64

[riperiperi]

LGTM, seemingly no regression on the games I have with multisampling.