If bounding box is enabled when a UID cache is created, then later disabled,
we shouldn't emit the bounding box portion of the shader.
Fixes pipeline creation errors on D3D12 backend for this case.
Since the copy X and Y coordinates/sizes are 10-bit, the game can configure a
copy region up to 1024x1024. Hardware tests have found that the number of bytes
written does not depend on the configured stride, instead it is based on the
size registers, writing beyond the length of a single row. The data written
for the pixels which lie outside the EFB bounds does not wrap around instead
returning different colors based on the pixel format of the EFB.
This suggests it's not based on coordinates, but instead on memory addresses.
The effect of a within-bounds size but out-of-bounds offset
(e.g. offset 320,0, size 640,480) are the same.
As it would be difficult to emulate the exact behavior of out-of-bounds reads,
instead of writing the junk data, we don't write anything to RAM at all for
over-sized copies, and clamp to the EFB borders for over-offset copies.
When looking into the Faron Woods fifolog, I noticed this code was quite
high in the profile (~10%). Clearing 4096 entries from the vector isn't
needed every draw, we only need to do this when the cache was actually
valid in the first place.
Should provide a slight general performance boost.
This was causing the depth buffer to be discarded as well, which
has an effect on mobiles (doesn't get loaded into tile memory).
If we find this is hindering performance (remember, the EFB is
only a 640x528 texture), it may be worth changing the interface to
support discarding only the colour buffer.
for this kind of footage carrying alpha information makes no sense, and it additionally complicates things by hugely damaging compatibility of the resulting video. after this change alone the video becomes compatible with VfW/WinAPI and tools that rely on it (avisynth, virtualdub).
fixes https://bugs.dolphin-emu.org/issues/11141 and https://bugs.dolphin-emu.org/issues/10193
