[azlekayn]

ea78039 made a capture wait for the GPU when it copies a page that a running submission still writes back, which fixed the exposure flashes. That wait runs on the game's main thread, about 8% of its time at a busy scene.

With this change the capture no longer waits. It records those pages, and the replay thread, which is idle about 45% of the time, waits for the submission and copies just those pages again before it uses the capture. Typically about 130 pages in a capture, and the replay waits 1.3-3 ms for them.

RX_VK_CAPTURE_WAIT=1 restores the wait on the game's thread, and =0 still removes it.

Measurements

Ryzen 7 7800X3D, RX 7800 XT, RADV, Fedora 44, 2560x1440, Kokiri Forest at the same ~2150-draw spot, runs alternating between modes (RX_VK_CAPTURE_THREADS=4 in all of them, see #876):

RX_VK_CAPTURE_WAIT	fps per run	mean	big flashes
1 (current behaviour)	43.3, 43.5, 42.5, 43.0, 43.9, 41.8, 45.1	43.2	0 in ~32,000 frames
2 (this PR)	46.8, 46.6, 46.8, 48.0, 47.3, 44.8, 45.9, 47.8	46.8	1 in ~41,000 frames
0 (no wait, 1 run)	47.7		575 a minute

A big flash is a frame where at least 20 of 144 screen blocks jump and return. The =0 row shows this scene does expose the original bug. Smaller artifacts would not be counted.

Known risk: please review this part

The late copy reads guest memory after the game's thread has moved on, so if the game writes to one of those pages between the capture and the late copy, the replay sees that newer data, a page from slightly later than the submit. The wait on the game's thread made that impossible. I saw one flash across about 41,000 frames, and I don't know whether this race caused it.

If you'd rather not change the default, flipping it to 1 keeps this as an opt-in.

What was and wasn't tested

• Runs were on 5c9b0bf plus perf(linux): hand guest memory to the GPU as udmabuf dma-bufs, not host pointers #448 and vk: batched submits: a progress poll flushes only after 2 ms by default #689, with the same logic plus a per-600-submit log line.
• The branch compiles on current main (Linux renderer), but I did not run this exact build. perf(linux): hand guest memory to the GPU as udmabuf dma-bufs, not host pointers #448 has since merged, so main now has what this card needs, but these runs predate that merge.
• One area (Kokiri Forest, the ~2150-draw spot) and one GPU/CPU. Not tested on Windows, NVIDIA or Intel, or in other areas.

🤖 Generated with Claude Code

[azlekayn]

Re-measured on current main (3b4347d, which has #689), with this PR and #876 merged on top. Both merge cleanly.

RX 7800 XT, RADV (Mesa 26.2.6), Ryzen 7 7800X3D, Linux. Same ~2150-draw Kokiri Forest balcony view, runs alternated between builds, default settings. Only the renderer .so differs. Frames were presented through a headless weston on the same GPU; a check run with this PR's mode gave the same fps as the real display (47.0 vs 46.8).

build	fps per run	big flashes
main	42.5, 42.5, 40.7, 42.3	0
main + #876 + #936	46.2, 47.2, 47.1	0
main + #876 + #936 + #896 + #948 + #989	48.8, 48.5, 49.0, 49.8, 48.0, 48.0, 48.4	0

Picture brightness matched across all builds in the screenshots (mean 80-82 of 255), so 0 flashes isn't hiding a broken image. I didn't measure #876 and #936 separately on this base, and I didn't separate #896, #948 and #989 from each other. This is one scene on one GPU. The race described in the PR body (the game writing a page before the late copy) still applies.