Better ways to deal with overlapping render targets

[hrydgard]

In #15717, I fixed the Juiced 2 rendering issue where two render targets share a bit of data by partially overlapping, by allowing PPSSPP to consider them the same render target. Since a lot of draws are done texturing from one and writing to the other, this leads to a lot of detected "self-texturing" which leads to a large number of expensive copies.

An alternative approach would be to leave the two render targets separate, but on bind, detect other overlapping rendertargets and copy the overlapping areas from the other ones if they're "fresher". A bit similar to what #15700 will do for depth buffers, but with an offset. That would avoid the self-texturing issue entirely, but adds a little bit of complexity that we might not always want to have enabled.

Anyway, if implemented, this should get Juiced 2 speed back to at least where it was before, so might be worthwhile in the future.

[hrydgard]

I've been thinking more about this and I'm convinced now that allowing multiple overlapping targets to exist with different formats and other properties to exist, and do the necessary copies on bindframebuffer similar to our existing depth copies, is really the way to go. Let's call this a "resolve". One wrinkle is that these resolves might need to happen when binding a texture in the wrong format, too - we'll then create the missing-format render target on-demand, and resolve to it (which will result in a reinterpret).

This makes it practical to allow overlapping framebuffers with multiple formats, even 32-bit vs 16-bit, and do reinterpret blits at bind time (hopefully we'll be able to bound these rectangles... maybe we even need lists of bounding rectangles that were updated at a specific time to solve stuff like Cars 2 efficiently). This can also solve the #9576 issue in a cleaner way.

I'm going to start with a small version of this that solves it for Juiced 2, and go from there.

[hrydgard]

I tried doing this for color-to-depth (#9576) with the help of #15853, but it turns into madness without deferred depth copies, so will have to do that first, or at the same time. Argh.