[AdyaGMD]

What and why

In Ocarina of Time (0400486024DEC000) the heavy frames on an M1 run about 150 encoders and 110 passes, and the GPU spends about 19% of its time in gaps between them. Compute work splits the scene passes, and cs_hoist_try, which moves a dispatch ahead of the pass it would split, never moved one. Every scan stopped at one of these:

• Occlusion queries. The game resets and reports a samples-passed query around nearly every scene draw (58 in one pass).
• Conditional rendering. Each object is drawn only if its query passed, so render-enable switches sit between the draws.
• Read-only storage buffers. Any storage buffer bound to a draw stopped the scan.
• Pending clears. A pass with clears waiting to land was not scanned.
• Uniform-buffer updates. The game writes about 80 a frame inside its scene passes.
• Game barriers. About 70 a frame between the scene draws.

Each case, and what this change does:

• Queries: a dispatch draws no samples, so it moves past samples-passed resets and reports as long as it reads and writes none of the reports' memory (16 bytes each).

• Conditional rendering: it skips draws and clears, never a dispatch, so a dispatch moves past it. If a dispatch writes the two counters a condition compares, the scan stops.

• Storage buffers: a draw's read-only storage buffer counts as a read range instead of stopping the scan.

• Clears:

  • A pending clear no longer stops the scan.
  • While a dispatch moves, the pass's pending clears are set aside, so it neither lands nor queues them.
  • A dispatch that touches none of a waiting clear's targets no longer forces the clear into a clear-only pass. The clear waits for the next pass to take as its load action.

• Uniform updates: a dispatch moves past an update whose bytes it neither reads nor writes. The updated range joins the ranges the scan checks.

• Barriers: a barrier orders nothing the moved dispatch depends on, for three reasons:

  • The draws before it in the pass write no memory and no attachment it samples.
  • Moved dispatches keep a barrier between each other, because each dispatch is recorded as writing everything.
  • The pass that opens after them starts behind a full barrier.

  Replay still runs the barrier at its original place, for the draws after it. DM_NVN_CSH_BARRIER=0 restores the old stop.

• Stats: a new log line names the ops that stopped the most scans. In Ocarina of Time, render-target changes are now almost all of them, and those really do end the pass.

Checked

• Ocarina of Time 0400486024DEC000 v131072, Mac app, M1, macOS 26, handheld, 30 fps target, opening and gameplay. The pass-dump and gpuprof data come from the same game.
  • Before: compute dispatches moved ahead of their pass 0.
  • After the query, conditional-rendering, storage-buffer and clear changes: 300 in 300 frames (about one a frame).
  • After the uniform-update and barrier changes: 760–900 in 300 frames.
  • waiting clears taken by a later pass: about 300 in 300 frames. The clears that still land on their own are cleared right before a dispatch that uses them.
  • The picture was right.
  • Gameplay went from 24–25 fps to 27–30 fps, measured together with the MetalFX upscaler PR.
  • In the heavy area at 1366x768, the uniform-update and barrier changes took play from 18–22 to 27–30 fps, and the median frame from about 44 ms to 33–36 ms. The heavy submission's GPU time went from 30–35 to 25–27 ms, and its attachment loads from 238–260 MB to about 200 MB. The two runs may not have been in exactly the same spot.
  • No new RED lines.
• Tests: dm/gfx/tests/t_perf_order.m was updated for csh_cs's new arguments. The GPU tests were not run locally (Apple-silicon Metal tests; CI has no Metal 4).
• Not checked: other games. This is host code every game runs, and no regress.py report was made. The new paths only add moves past ops the scan used to stop at. Each is guarded by the memory ranges it reads or writes, except barriers, which rely on the ordering described above.

Docs

• No reference entry: this is a scan rule in nvn_mtl.m, described in its comments
• No game files, keys or data extracted from a game in the change or the attachments

🤖 Generated with Claude Code

[cover93-95]

iPhone test: no dispatch moved

Setup: same as my #1970 report. iPhone Duo (iOS 27.2), Ocarina v131072, docked, 30 fps, the game's own NDSR upscaler (not MetalFX), main pass 2048x1152, Deku Tree, ~8 min. This PR was picked together with #1970 onto main 37f076a + a few fixes.

• compute dispatches moved ahead of their pass: 0 for the whole session.
• compute hoist … scans stopped by op: 8=25978 38=432 5=300, i.e. almost always OP_SET_RT, then 38 (OP_CLEAR_TEX if I count the enum right) and OP_REPORT_COUNTER.

So here the game's dispatches seem to sit right after a render-target change, at the start of a pass, and the scan never gets past it. Your run was handheld with MetalFX. Could docked plus the game's own upscaler change where the dispatches land? Happy to run a build with more logging if that helps. No picture issue seen (nothing moved, as expected).

[AdyaGMD]

Thanks, this matches what I'm seeing on the Mac. There, about 27,000 scans per 300 frames stopped at op 8 (OP_SET_RT), and the moves came only from the few that got past it.

The game sets its scene targets again before each group of compute between its draws. Replay already continues the pass across a switch to the same targets (same-target continuation), but the hoist's scan stopped at every OP_SET_RT. So docked or not, with or without MetalFX, a dispatch right after such a switch never moved. That fits your 0.

I've added a commit: the scan goes past a render-target switch when replay would continue the pass across it, meaning the same targets, the continuation on, and not a deferred pass's start. Any other switch still stops it. The stats line now also prints same-target switches passed N, which tells us whether the switches are really to the same targets. It hasn't been run yet. If you can run it again in the Deku Tree, the numbers to look at are moved ahead of their pass, the new count, and the scans stopped by op list.

38 is OP_CLEAR_TEX, yes.

🤖 Generated with Claude Code

[aCidcOde]

Data point from an M4 Pro (MacBook Pro, 24 GB, macOS 26.7.2), Ocarina of Time v131072. This change, at 6a512fa, was ported onto our tree (an older main): 7 of 8 hunks applied as is, and the lc_land line was placed by hand because our condition has (g_ret_n || g_nrest).

Tests: check_t_perf_order fails 1 of 36: explicit game barrier prevents hoist. It passes 36/36 with DM_NVN_CSH_BARRIER=0.

• In that case the dispatch writes only the storage buffer, and the draw before the barrier writes only the colour target.
• The new barrier rule therefore allows the move, and the check's expectation looks out of date.
• compute writes expected shared memory still passes.
• The check is unchanged on this branch (t_perf_order.m:153), so it probably fails there too. The description says the GPU tests were not run.

Game: Kokiri Forest route in a window, from the same save copy each time, comparing this change with DM_NVN_CS_HOIST=0. Without this change, our build moved 0 dispatches, as in the description.

	with this change	DM_NVN_CS_HOIST=0
dispatches moved per 300 frames	about 900	0
GPU p50, first 4 windows (ms)	15.5, 16.8, 15.8, 12.2	15.4, 16.9, 15.9, 12.6
frame p50, same windows (ms)	17.4, 18.6, 17.6, 16.6	17.3, 18.6, 17.6, 16.6
RED lines / picture	0 / right	0 / right

About 3 dispatches a frame moved, which matches uncraftablexd's M4 Pro count above. On this GPU there was no measurable gain, so for now our build for the player leaves the change out.

These numbers are for 6a512fa. The render-target switch commit that came after it (7d26a8d) was not tested.

[dpadr]

At head 7d26a8d, dm/gfx/tests/t_perf_order.m fails its own barrier check: "explicit game barrier prevents hoist".

This PR lets the hoist pass a game barrier when the draws before it write no memory (csh_bar_pass(), on by default). The test still expects no hoist whenever a barrier is present. It gets one hoist, so the check fails.

A one-line fix that keeps both behaviours covered: expect a hoist exactly when csh_bar_pass() allows one.

-        CHECK(hazard?"explicit game barrier prevents hoist":"independent dispatch hoisted once",g_csh_moved-before==(cshoist_on() && !hazard));
+        CHECK(hazard?"explicit game barrier: hoist only when barriers can be passed":"independent dispatch hoisted once",g_csh_moved-before==(cshoist_on() && (!hazard || csh_bar_pass())));

With that change the test passes here. I also ran the PR on Ocarina of Time (0400486024DEC000 v131072) on a MacBook Air M2 (10-core GPU, 16 GB), macOS 27.0: handheld at 1440x810, Kokiri walk, in-run A/B, 8 pairs at ~3.0 GHz. GPU p50 went down 0.05 ms [−0.09, −0.035] and the frame went down ~0.035 ms. That's small but consistent. On this M2 the scans mostly stop at render-target switches, not at the cases this PR handles.

🤖 Generated with Claude Code

[XIIYAZ]

This PR conflicts with main in nvn_mtl.m: since it was opened, main added NVN_RB_SBUFQ to the cases that stop the scan. How I merged it so both changes hold:

• csh_draw_reads: keep this PR's read-only NVN_RB_SBUFP case, and put main's NVN_RB_SBUFQ into the refusing line: case NVN_RB_SBUFU: case NVN_RB_SBUFQ: case NVN_RB_IMG: case NVN_RB_TBUF: case NVN_RB_GMEM: return 0;
• csh_cs: keep this PR's CBUF / UBOP case that also records the read, with the same NVN_RB_SBUFQ added to the refusing line after it.

I've played Ocarina of Time on that merge for several days on an M4 Max, with no stutter and no picture problem.