[crypt0dj]

What and why

mesh_tasks_draw leaves a draw out when mtk_pso returns nil, which it does until the background build of that pipeline finishes (dm/gfx/nvn/nvn_geometry.inc, "its draws are left out until it is ready"). The sibling geometry-mesh path counts and reports the same thing through mtl_geomesh_stats, but g_mtk_wait was only incremented, never read: nothing in the log said a frame was missing geometry, or how much of it. A whole-repo grep finds it at its declaration and its increment and nowhere else.

This adds mtl_mtk_stats and reports it beside the geometry mesh line, marked [RED] in the intervals that dropped a draw.

What it measured, on an M1 Max, Ocarina of Time 0400486024DEC000 v131072, chain 3ee52af3ca18:

frame 1200: 24432 draws, 222 dropped   [RED]
frame 1500: 21354 draws,   4 dropped   [RED]
frame 2700: 21493 draws,   2 dropped   [RED]
frame 3000 onwards:        0 dropped

That run built 62 task / mesh pipelines, each taking 57 ms to 5,356 ms. The window matches when this game's foliage shows white shapes after a load and when it stops: a depth pre-pass and a colour pass are separate pipelines and become ready at different times, so a pre-pass that is ready writes depth for geometry whose colour draw was dropped.

That those white pixels are these draws is not shown. DM_NVN_SKIP_MESH=1 cannot decide it — dropping both passes removes the depth write too, so the frame is simply short of foliage either way. Showing it needs the near-white share of shots taken inside the window (white.py in this game's work folder, which was not available on the test machine). The game note keeps it open.

Related, found on the way and not addressed here: mesh pipelines never look in the pipeline archive. nvn_geometry.inc:434 and :585 build straight on the device, while the other path tries g_arch4 / g_arch4p first, so these pipelines are rebuilt on every run and the window exists every time.

Game note: dm/games/0400486024DEC000/README.md, under Open. No reference entry: the mechanism is reported, not yet explained.

Checked

• Tests: dm/tools/tests/test_docs.py (11), dm/tools/tests/test_nsp_chain.py (17), and the host builds (make -C dm/host GAME=0400486024DEC000)
• Games run, with title ID and version: Ocarina of Time 0400486024DEC000 v131072, about 15 minutes on the Mac over a 5,100-frame run, reading the new log line against the task / mesh pipeline build times in the same log
• Devices and OS: MacBook Pro M1 Max, macOS 27.0.1 (26A434), applegpu_g13s
• No scripts/regress.py check --games report. This adds a log line and an accessor and changes no behaviour or code path. regress.py list on this machine shows three games, all baselines: none, green: never recorded, so a run would first have to build baseline and candidate shader trees — hours per game. Flagging it rather than omitting it; say the word if it should be run anyway.
• Measurements before and after: not applicable, nothing here affects speed, memory or power

Docs

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

🤖 Generated with Claude Code

[crypt0dj]

Correction and credit: the paragraph above about mesh pipelines bypassing the pipeline archive reads as a finding of this PR. It is not. #1583 already documents it, and its mesh_archive probe goes further than this PR does:

A mesh pipeline built through MTL4Compiler is stored in a Metal 4 archive and found again (0.18 ms, against a 36 ms build). The host builds mesh pipelines with newRenderPipelineStateWithMeshDescriptor, which bypasses the archive.

That settles the question this PR left open, that the fix is possible at all: MTL4Compiler does archive a mesh pipeline, so the bypass is the host's and not a Metal limit.

Two more things a reviewer may want beside this:

• The Legend of Zelda: Ocarina of Time (0400486024DEC000): renderer, shader and pipeline archive fixes through the Forest Temple #1590 builds task / mesh pipelines on QOS_CLASS_USER_INITIATED in mtk_pso. That shortens the window the counter here measures without closing it, so the two do not conflict: with The Legend of Zelda: Ocarina of Time (0400486024DEC000): renderer, shader and pipeline archive fixes through the Forest Temple #1590 in, the numbers should fall but not reach zero.
• dm/games/0400486024DEC000/pso_manifest.tsv exists (1.3 MB), yet the measured run still built 62 task / mesh pipelines on the spot. The prewarm list is already configured for this game and does not reach these pipelines, which is consistent with the bypass above.

This PR still only reports the drops. Nothing here changes behaviour, and the fix is left for the work on the archive path.