[dean0396]

What and why

mdi_wait (dm/gfx/nvn/nvn_mtl.m:13371) ends the render pass and commits the main command buffer in the middle of a submission, then waits for the GPU so the replay can read on the CPU what the GPU wrote: an indirect-count multi-draw's count, a geometry draw's indirect record, an indirect dispatch's grid when its threadgroup memory spills (tg_spill), or memory for DM_NVN_UBP_CHECK. The other two commits of g_cb, mtl_sub_commit (2390) and sub_cut (15004), call gmem_commit_patch() before they end the command buffer. mdi_wait doesn't (13374 goes straight from up_flush() to res_commit()).

So the window that 339d9f2 (PR #1427) closed for whole and segment commits is still open at this one:

• An argument block encoded before the wait keeps the raw pool table it was encoded with. A pool made between that encode and the wait's commit isn't in the table the GPU searches, and a raw read of it gets 0.
• The block's word stays in the noted list, so the next commit (a segment or the end of the submission) rewrites it after the GPU has already run the block. It also moves the block's write log (NvGmlLog) to the newer table, so gml_read decodes bits the shader set against the old table against the new one.

The fix is the same call in the same place as sub_cut: gmem_commit_patch() after up_flush() and before res_commit() / endCommandBuffer. It clears the noted list, so the next commit only patches blocks encoded after the wait. In the host that's the one call and its comment, plus the comment above NvGmlLog, which now lists the count wait's commit too.

I found this by reading the code, not in a game. Ocarina of Time, the game I play, never reaches mdi_wait (no "indirect-count multi-draw" line in its logs), so this is for games that do. Going by docs/reference/rendering.md, those are geometry draws that can't be masked on the GPU (Donkey Kong Bananza as a level opens) and draws that need a CPU count (quads, fans, 8-bit indices).

Overlaps:

• Transform feedback: the capture state on the CPU, captures share one pass #2114 (transform feedback) also edits mdi_wait: it adds if (g_tf_enc) tf_pass_end(); at the top and right after up_flush(); res_commit();. Its mdi_wait hunk no longer applies on top of this change. In a merge only its second line conflicts. To resolve it, keep up_flush();, gmem_commit_patch(); and res_commit(); from here, then its tf_pass_end(), the order it already uses in sub_cut.
• Large pools held once in the residency set: segments take covering chunks' buffers, one buffer per pool past its size, a grown pool keeps it (stacked on #1407; PRAGMATA on an 8 GB Mac) #1614 makes the same kind of call at the same place in its own design: its gmem_segment_commit(), which calls gmem_commit_patch(), runs in mdi_wait between up_flush() and res_commit().
• Raw global memory at Metal's own GPU addresses, opt-in per game (shader_raw_direct, Ocarina of Time) #1833 (shader_raw_direct) also changes gmem_commit_patch and t_gmem_words. It changes table_has to take the pool pointer and drops a, so whichever of the two goes in second needs the new check written as table_has(w8, mem + 48 * MB). Under its mtl_gva_on mode, gmem_commit_patch is also where the pools are made resident before a commit, so with both in, the count wait's commit does that too.

Checked

• Tests, on upstream/main 8fb5ffe:
  • t_gmem_words with the new case (a word that holds the table from before a pool was made, then mdi_wait(), must point at a table that holds that pool, and no word may be left noted after it): with only the test change, 18 checks, 2 failed (the two new ones). With the fix, 18 checks, 0 failed, 5 runs in a row.
  • make -C dm/gfx/tests GAME=0400486024DEC000 run: 135 of 136 tests pass. Among them are t_large_mdi, t_geometry and t_tg_spill, which also go through mdi_wait. They don't use the raw pool table, so they only show that nothing else broke. The other one, t_feedback, fails its check "with nothing running: a commit" now and then, on an unmodified export of main too (3 of 6 runs on main, 4 of 6 with this change). It doesn't reach mdi_wait.
  • python3 -m unittest dm/tools/tests/test_docs.py: 6 tests, OK. I ran python3 dm/tools/docs_symptoms.py, and the symptom index doesn't change (only the entry's Fix and Check lines did).
  • The Mac host builds: make -C dm/host GAME=0400486024DEC000 dmhost.
• Games run: none on main. Ocarina of Time, the only game built here, doesn't reach mdi_wait. The same change has been in my own fork's builds since November 8. That's where I play Ocarina, so it never runs there either.
• Devices and OS: M3 Max, macOS 26.7.2.
• regress.py: not run. Only Ocarina of Time is built here, and it doesn't reach this path, so a report from it couldn't show anything. The change only does something when a submission reaches mdi_wait with words noted since the last commit.
• Also not run: lint_c.py (no clang-tidy on this machine), iOS.

Docs

• The finding is in its game note or its docs/reference/<subsystem>.md entry, and python3 dm/tools/docs_symptoms.py was run (the symptom index): the Fix and Check lines of "Raw pool table words that predate the pools" in docs/reference/shaders.md now name the count wait's commit
• A chain tool changed: dmsh_chain.py --header was run and dm/gfx/nvn/dmsh_chain.h is part of the change (no chain tool changed)
• No game files, keys or data extracted from a game in the change or the attachments