[NotRexed]

Implements #1993's proposal by @mrdev023, as a default where batching is on.

With batched submits (on by default with RADV, so Linux AMD including the Steam Deck; RX_VK_BATCH=1 elsewhere), a held batch waited for the next wait, present or the 32-buffer cap. That happened even when the GPU had finished everything it was sent. So the GPU sat idle until the game waited for it, and with serial replay that's mid-frame, at take_capture's late-page wait.

Now, when a submit joins the batch and the GPU has completed every batch sent so far (batch_tl >= batch_flushed), the batch goes out at once. While the GPU is busy, submits are still grouped.

The reporter's numbers (RX 9070 XT, RADV, Kokiri Forest, FSR 4, 5120x1440):

build	fps in play	flashes (framelog, 5+ blocks)
main	33-41	0
idle flush	46-61	0 in 5230 frames

Flushes went from about 5.7 a frame to about 10 of 3.7 command buffers each, and the late-page wait from about 1.4 to 0.64 ms.

RX_VK_BATCH_IDLE=0 keeps the old behaviour.

Not yet checked here: I have no RADV machine. I'll A/B it on Windows with RX_VK_BATCH=1 (NVIDIA) for fps and flashes before merging. Drivers other than RADV are unchanged, since batching stays off there by default.

🤖 Generated with Claude Code

[mrdev023]

Tested this branch as is (35a8aaa on main abd5e5f) on RX 9070 XT, RADV, Ryzen 9 9950X3D, NixOS. Kokiri Forest, FSR 4 at 5120x1440, GPU power level auto, same build both ways:

	fps in play	framelog events of 5+ blocks	flushes a frame	late-page wait a frame
RX_VK_BATCH_IDLE=0	29-38	0 / 2068	~4.1 (14.1 cbs each)	~7.9 ms
this PR	41-57	0 / 3044	~14.5 (4.0 cbs each)	~4.6 ms

Same gain as in #1993, no flashes.

[NotRexed]

A/B on Windows (RTX 4060 Ti, batching forced on with RX_VK_BATCH=1), smooth.ps1's route (Kokiri Forest, Hyrule Field, Kakariko), 2 rounds alternating:

run	median	p99	crashes
batching off (Windows' default)	59 / 59 fps	29.1 / 29.5 ms	0
batching on + idle flush (this PR)	59 / 58 fps	28.9 / 31.5 ms	0
batching on, held (RX_VK_BATCH_IDLE=0, before this PR)	47 / 46 fps	34.1 / 37.3 ms	0

With the batch held, the GPU sits idle and loses ~12 fps here, matching what #1993 measured on RADV. The idle flush brings batching back to the unbatched frame rate, and Windows' default (batching off) is unchanged.

🤖 Generated with Claude Code

[mrdev023]

the description's late-page wait (~1.4 -> 0.64 ms) doesn't match #1993's or mrdev023's per-frame numbers (~7.9 -> ~4.6 ms)

Those came from my first write-up in #1993, and they were my misreading. The log line a capture taken (ms): ... GPU wait for late pages X (100 of 600 takes) averages over all 600 takes. There are 6 takes a frame and the wait falls in one of them, so the per-frame wait is 6 × X: ~8.4 -> ~3.8 ms in #1993, ~7.9 -> ~4.6 ms in my rerun of this branch. I've corrected both. The relative gain is unchanged.

The catch is that both runs are one machine (9070 XT + 9950X3D at 5120x1440 with FSR 4), and that machine is GPU-bound.

I don't think it is, after profiling it today (main abd5e5f + this PR, Kokiri Forest):

• Render scale barely matters: FSR 4 Native AA -> Performance (50%) -> Ultra Performance (33%) gave 46 -> 50 fps at best. GPU time stays at ~11-14 ms a frame for a ~19-21 ms frame.
• HOS_SAMPLE_ALL + scripts/crit.py: the main thread runs ~18% of the time. It waits ~25% in take_capture's GPU wait and ~35% in event_wait for the Presentation thread, which does the replay. The replay costs ~14-20 ms of CPU a frame (a frame's replay time: draw 6-10, descriptors 2-4, commands 2.5-4).
• RX_VK_PASS_TIMING=1: the GPU's work is ~175 passes (~39 us each) and ~143 dispatches (~21 us each), with ~409 full barriers a frame. That looks latency-bound (many small serialized pieces), not throughput-bound, which is why the resolution doesn't change it.

So on this box the frame is the CPU replay plus the mid-frame wait, and the GPU mostly waits for work. That also explains why RX_VK_BATCH=0 was faster than the held batch: the GPU sat idle while the batch was held.

@hckrman101