VideoBackends:Metal: Allocate bounding box uploads on a cpu buffer

[TellowKrinkle]

AMD Metal drivers have a goofy bug where the bbox buffer stops being coherent with the cpu if you copy to it from a private (gpu) buffer and don't do anything else with it in that command buffer.

Test case available here if anyone's curious

The old way was actually missing a required fence wait on the upload fence (to prevent the GPU from attempting the copy before it uploaded the copy source), but that's not the actual cause of the breakage, as indicated by the above test case, which doesn't disable hazard tracking and therefore doesn't have any fence requirements.

Side note, if anyone has any AMD GPUs running not-Ventura, please run the linked test case and report back, I'd love to figure out if that bug is new or if it's been around for a while.

[OatmealDome]

Tried the testing program on a MacBookPro16,1 running macOS 12.4, and it fails.

$ ./AMDCoherency 
Intel(R) UHD Graphics 630
1024 1024 0 0
256 256 511 511
256 256 511 511
AMD Radeon Pro 5500M
1024 1024 0 0
1024 1024 0 0
1024 1024 0 0

Also, to fix the build failure, rebase onto latest master.

[TellowKrinkle]

Tried the testing program on a MacBookPro16,1 running macOS 12.4, and it fails.

Good to know
For reference, I've tested it on a 13.3.1 (a) MacBookPro16,4 (UHD 630, Radeon Pro 5600M), and a 11.7.5 MacBookPro11,3 (Iris Pro 5200, GT 750M), and so far only AMD has been broken

The in-dolphin effect is bbox sometimes breaking, I had the ttyd boat flip scene break fairly consistently off one save state but not off another and not off running from the start with no save state load, which was fun

[iwubcode]

So is this still in draft since Oatmeal had some issues?

[TellowKrinkle]

No, those issues are on a test program meant to reproduce the failure that this PR works around

(And I did rebase onto (then) latest master, which is why there are no more build failures)