[azlekayn]

What this fixes

With RX_VK_BATCH on (the default on RADV), get_replayed() sends the held submits on every progress poll, because RX_VK_BATCH_POLL_US defaults to 0. The game polls many times a frame, so most flushes come from polls, and each one is a full command submission. That is the cost batching exists to avoid.

This makes the default 2000 µs, as suggested in #413 and #528. A poll then flushes only once the oldest held submit has waited 2 ms. RX_VK_BATCH_POLL_US=0 restores the old behaviour. Flushes for waits, values, slots and presents are unchanged, so held work is delayed by at most 2 ms on the poll path.

Measured

RX 7800 XT, RADV, Kokiri Forest, Link idle on the balcony at about 2150 draws. 60 s per run, 2 runs per setting, on one build with the settings interleaved.

RX_VK_BATCH_POLL_US	fps	poll flushes per 120 presents	big flashes
0 (old default)	38.5, 37.6	525	0, 0
2000 (new default)	42.2, 43.1	67	0, 0

An earlier sweep on 7e9bf73 + #448 was flat from 1 to 16 ms: 41.4 to 43.7 fps against 37.1 and 37.3 for 0.

Not covered

• The build was current main (5c9b0bf) + perf(linux): hand guest memory to the GPU as udmabuf dma-bufs, not host pointers #448, because main alone falls back to very low fps on this card. The renderer was swapped into a game built from 7e9bf73.
• Only one card and one scene were measured. Other RADV reports (AMD/RADV (Linux): ~10 fps because each vkQueueSubmit2 costs ~13 ms – batching the replay's submits gives 30-50 fps (patch attached) #413 on a Radeon 8060S, [AMD RX 9070 / RADV Linux] Low FPS (22-25) in Kokiri Forest + color distortion & background flicker #528 on an RX 9060 XT) saw the same effect with this setting set by hand.
• Non-RADV drivers only reach this path with RX_VK_BATCH=1.

🤖 Generated with Claude Code