[AdyaGMD]

What and why

Follow-up to #1087 (landed as 84ec307): in Donkey Kong Bananza its mesh draw runs never form. The log reads 0 of them in 0 runs in every heavy frame.

Cause: geo_mesh_run_fits refused runs while samples-passed counting was on (g_vis_counting), and counting stays on for the rest of the game after the first samples-passed reset: mtl_exec sets the flag and nothing clears it (only a deferred-pass replay does, for its own replay). Bananza resets that counter once, so every geometry draw of its depth prepass was dispatched alone, although the heavy frames have no samples-passed report at all.

Fix: runs are allowed while counting is on. A report ends a run before it executes (it is not in geo_mesh_keeps), and a pass keeps one query slot (g_vis_cur), so each query's interval holds whole runs, never part of one. Whether any of its samples passed is then the same in any order of the run's draws (the nearest fragment of each pixel passes whatever the order), which is what occlusion tests and conditional rendering ask; only the exact count can differ by fragments another order rejects. The other conditions stay (no colour or stencil writes, an order-free depth test, a fragment shader with no resources). A draw that cannot join a run now logs why, once per reason (geometry mesh run: a draw of vertex … draws alone: …), so a refusal cannot hide again.

Reference: Mesh geometry draws gathered into one dispatch, updated.

Checked

• Games run, with title ID and version: Donkey Kong Bananza 040074A01BF12000 v458752, handheld, the heaviest view of its heavy area, with the MetalFX upscaler (A game's own upscaler drawn by MetalFX, the player's choice in the launcher: Donkey Kong Bananza's NDSR network 3.5-5 ms → about 1 ms a frame on an M1 #1086) and the border-colour change (Pixel shaders without the border-colour correction in their main library: it spilled registers in every pixel where it never ran #1032), DM_NVN_GPUPROF=every:60:
  • before: 166,883–226,822 mesh draws per 300 frames, 0 of them in 0 runs;
  • after: 142,044–154,834 mesh draws per 300 frames, all of them in 300 runs (one run of about 475 draws a frame), ended by the next non-mesh draw (298–300) or an operation (0–2).
  • The two runs' views had different draw counts (about 7,870 and 6,600 a frame), so their frame times are not a like-for-like comparison.
• Devices and OS: MacBook Pro (13-inch, M1, 8-core GPU), macOS 26.6.2, Xcode 27.2.
• Tests: not run for this change on this machine. check_t_geometry_mesh does not turn occlusion counting on, so it does not cover this case; a case with a samples-passed reset before the draws would.
• scripts/regress.py: not run; the shader chain does not change (host only).

Docs

• The finding is in its docs/reference/shaders.md entry; python3 dm/tools/docs_symptoms.py was run
• A chain tool changed (no)
• No game files, keys or data extracted from a game in the change or the attachments

🤖 Generated with Claude Code

[seedds]

Thanks. The diagnosis is right: g_vis_counting never clears after the first samples-passed reset, so the old rule meant no runs in any game that had used an occlusion query. The any-passed argument holds too. I'm not landing it tonight only because nothing here can exercise it: no local game draws mesh runs with counting on (NieR's route needs its opening-flight save, which isn't on this machine), and the run changes exact counts when depth writes are on. Two things would let it land: a t_geometry_mesh case with a samples-passed reset before the draws (one run with depth writes, a report after it, the count nonzero and the picture the same as single draws), and a before/after screenshot of the Bananza scene you measured.

[seedds]

Landed on main as 53ab7a9, with you credited as co-author, plus the test I asked for, which I wrote myself: t_geometry_mesh now draws its runs again with a samples-passed reset before them and a report after. The draws must join runs, and the report must equal the pixels they wrote. It fails on main's nvn_geometry.inc and passes with your change (runs, single draws, encode thread). regress.py check on BotW, Wonder and TotK showed no new red lines and unchanged fps. Thanks!