[AdyaGMD]

What

The M1 and M2 have no mesh-shading hardware (Apple9 / M3 and later do). On them, any render pass with a mesh draw costs 0.14–0.24 ms more, and the mesh stage runs about 20 % slower per meshlet than the same code as a compute kernel. With DM_NVN_MESH_COMPUTE (on by default on a Mac whose GPU lacks MTLGPUFamilyApple9, i.e. the M1 and M2; =0 turns it off; off elsewhere), task and mesh shaders run as kernels before their render pass, and their triangles are drawn with a plain indexed draw.

• Look-ahead (mk_hoist_try): the draw that opens a pass scans ahead through it, like cs_hoist_try does for dispatches. Every task / mesh draw it meets becomes a job.
• One compute encoder before the pass, in phases with a barrier between each:
  1. mk_ind: indirect records → dispatch and draw arguments.
  2. Task kernels.
  3. mk_scan: a scan of the task launch counts.
  4. Mesh kernels.
• Replay draws each job as an indexed draw: the side library's pass-through vertex function plus the game's fragment shader (mk_pso, built in the background; the native mesh draw is used until it's ready).
• Side libraries: <key>_bk.metallib, generated from the translated source by the new dm/gfx/tools/dmsh_meshcompute.py. A mac-app build runs it (mesh_side_libs in build_ipa_from_nsp.py, reused while the library and generator are unchanged), and pack_app.py --msl-extra adds them to the app's shader image. A failed generation leaves them out; without one, a draw stays native.
• Where the scan stops: at a draw that may write memory, a dispatch cs_hoist_try didn't move, another render target, and other ops. It passes uniform updates, but keeps native any draw whose uniform buffers or indirect record one of them touched.
• Indirect draws: each (record, mesh shader) has a GPU-written feedback slot holding the largest count seen and, for task draws, the largest meshlet total. These size the next frames' slots. The first time a task draw's record is seen, it draws natively while a probe records its count.

The grass flicker it had on the way

The first sizing reserved count × 32 meshlets per task. A colour-pass shader with a ~100-byte vertex record went over the 64 MB limit and stayed native, while its depth prepass shader (a 16-byte record) converted. The colour pass tests for equal depth. The kernel's position can differ from the mesh stage's in the last bit, so the test failed on scattered pixels and grass blades flickered white. Sizing from the meshlet totals the GPU actually counted fixed it.

Performance

Ocarina of Time (0400486024DEC000), Kokiri Forest looking down at the map, MacBook with an M1 (8-core GPU), fullscreen 2880×1800. Mesh compute was alternated on and off every 600 frames within one run. Frames 1500–4800, the second 300 frames of every turn:

	GPU p50	Frame p50
Mesh compute on (3 turns)	34.3–35.7 ms (mean 34.6)	36.9 ms
Off (3 turns)	35.1–36.6 ms (mean 35.9)	38.2 ms

−1.3 ms per frame (3.6 %), and on was lower in every adjacent pair. 82 % of mesh draws convert (78,829 of 95,766 over 1,800 frames). The rest are shaders with no side library (per-primitive outputs, point topology), first sights, and pipelines still building.

Separate runs drifted 3–4 ms apart (window state, time into the session), which is more than the gain. So DM_NVN_MESH_COMPUTE accepts ab for the existing DM_AB phases.

Switches (all diagnostic, in docs/env_switches.tsv)

• DM_NVN_MESH_COMPUTE=0|1|ab: the feature (default on for M1 / M2 Macs).
• DM_NVN_MK_IND=0|task|notask: which indirect draws convert.
• DM_NVN_MK_UBSTOP=1: end the look-ahead at the first uniform update.
• DM_NVN_MK_EQ=1: keep shaders drawn with an equal depth test native. It made things worse; kept for diagnosis.

Second commit

• On by default for M1 / M2, and the side libraries packed into the app (checked: an OoT mac-app build put all 492 into the app's image).
• The first commit didn't compile on main: it used a memory-write tracker and a same-target check from my working tree. Now a draw that may write memory is prog_swrites, and any target change ends the look-ahead. The measurement above was made with the working tree's versions; on main the scan may stop sooner in passes that change targets. This branch's host hasn't been run in game.

Known / not run

• For about 3 s after the start, while pipelines build and records are first seen, a prepass and its colour pass can take different paths, and the grass flickers. Building the pipelines while the game loads would fix that.
• Not run:
  • The DM_AB form of the switch in game (the measurement used an equivalent switch of its own, folded into DM_AB for this PR).
  • Any test suite.
  • iPhone.
  • M3 and later (it stays off unless set).
  • Other games.
• The generator's output was checked identical, for all 512 of OoT's mesh / task shaders, to the side libraries that were measured.

🤖 Generated with Claude Code

[devMlGUE]

Tested this on an M1 Pro (16-core GPU) in a tree with main b06f4e0 and your other M1 PRs merged (#2577 #2574 #2573 #2560 #2559 #2526 #2561 #2441 #2593, not #2525). Built from my own copy; all 512 side libraries compiled, 0 failed.

Found a visual issue: grass flickers and some flowers turn solid bright white. It started around frame 37,500 (I'd been around Hyrule Castle for a while and walked to the Market at the end), and from then on almost every log window had "indirect task draws had more meshlets than their slots (later tasks dropped that frame)", 31 times with 6 to 20 draws each. The slots kept growing (256 → 401 → 641) but the drops kept going until I quit. With only DM_NVN_MESH_COMPUTE=0 the flowers look right, the grass stops flickering and those lines are gone.

One note on the merge: main now skips cs_hoist_try in passes that replay deferred draws (!defer_q_draw), so I added the same check to the mk_hoist_try call when resolving the conflict. Happy to test a fix.