[Romen-Adama-Dev]

What

The translator's shared memory byte store (SharedStore8, also the 16-bit SharedStore16) was a compare-and-swap loop on the word, from upstream Ryujinx. GenerateSharedStore now clears the field with an atomic AND and sets it with an atomic OR. Lanes writing other bytes of the same word commute with both, so the word ends as the loop left it, without retries. A chain change: translator rebuilt, dmsh_chain.lock and dmsh_chain.h updated (chain 26a894c0f40a), the StageMemory test checks the new form. DM_NVN_SKIP_MESH=1 drops every task / mesh draw (as DM_NVN_SKIP_FS drops draws by fragment shader): how the cost was isolated.

Why

A task or mesh shader writes its primitive indices and count as bytes (0x927 modes 0x80 and 0x88). The 32 lanes of a workgroup write neighbouring bytes, so four lanes contend for each word and the loop ran about four times a store, with a divergent retry each time. Ocarina of Time's foliage mesh shaders have ten such stores a lane, over tens of thousands of workgroups a frame.

Semantics: two lanes writing the same byte at once now get a mix of their values where the loop gave one of the two; the hardware's order between them is undefined as well. No shader seen writes the same byte from two lanes.

Measured

The Legend of Zelda: Ocarina of Time, Kokiri Forest, M3 Pro (18 GB), DM_NVN_GPUPROF=every:600. The pass after the opaque pass holds the foliage mesh draws; a render pass's start stamp is written after its vertex stage, where Metal runs the object and mesh stages, so the mesh work shows as the gap before that pass or as its duration.

Run	Foliage pass	Frame	Internal resolution (the game's controller)
main (671c68e), as shipped	8.3-8.6 ms	25-28 ms, 36-40 fps	854x480
mesh draws dropped (DM_NVN_SKIP_MESH=1)	-	18.4 ms	1440x810
mesh bodies emptied (groups still launched)	~0	16.3 ms	1440x810
this change, the forest's 39 mesh shaders rebuilt by hand	3.5-4.0 ms	20.7 ms, 48 fps	1440x810
this change, full chain rebuild on top of 0f510fd (chain 26a894c0f40a on 0f510fd; rebased on e0dc79c as chain 3938bdc7c7c0)	4.9-5.4 ms (a denser view: 815-824 draws in the pass before, against 409-425)	20.8 ms p50, 22.0 ms p95, 48 fps	1120x630

Every run follows the same scripted route from the same save; the last row comes from the packed app, with 10.0 GB resident and no new [RED] line. The empty-body run shows the cost was in the translated body, not in launching the groups; the remaining 3.5-4.0 ms is the body itself (zeroing of the stage memory, loads, the output copy).

Checks

• DMSH_TEST_XLATE=dm/gfx/tools/dmsh_xlate_bin/dmsh_xlate python3 dm/gfx/tests/test_dmsh_ampere_mem.py: 64 ok (the byte store has the two atomics and no compare-and-swap).
• python3 dm/gfx/tests/test_dmsh_meshstage.py: 26 ok. python3 dm/tools/tests/test_nsp_chain.py: 17 ok. python3 dm/tools/tests/test_docs.py: ok.
• scripts/regress.py check --games: not run, this Mac has only Ocarina of Time. The change reaches every game whose compute, task or mesh shaders store bytes or half-words in shared memory; a run on the usual five would be welcome.

Docs

• docs/reference/shaders.md: "Stage memory byte stores through a compare-and-swap loop" (Symptom / Cause / Fix / Check / Found on), symptom index regenerated.
• dm/games/0400486024DEC000/README.md: a line under "Found on this game".

[Romen-Adama-Dev]

Rebased on main e0dc79c (the chain changed under it with the HMMA commit): translator republished on the current sources, lock and header updated, chain 3938bdc7c7c0. The 64 StageMemory tests, the mesh stage, chain and docs tests pass again. Nothing else changed.

[seedds]

Thank you: landed in ffebfd5 (chain f9f01e4f9994), with you as co-author. Your diagnosis (the byte-store loop in the mesh shaders), your measurements and DM_NVN_SKIP_MESH are kept. The fix itself is different:

• Instead of an atomic AND then OR, the shader build replaces the helper's loop with one store of the byte or half-word through a narrow pointer (dmsh_build.py shared_store_msl; the translator names the helper dmsh_shared_store8/16_<n> so the build can find it). Metal's threadgroup memory takes byte stores, and each byte is its own memory location, so neighbouring threads need no atomics.
• The reason: with AND / OR, two threads writing the same byte leave the OR of both values, a value neither wrote; the new GPU test (test_dmsh_shared_store.py) shows exactly that for AND / OR. The store leaves one of the two values, as the loop and the console do.

Measured on an M6 (12 GPU cores), Ocarina of Time standing on the Kokiri Forest deck, three runs each: the loop, the store and your AND / OR all give 14.0-14.6 ms GPU p50, against 10.3 ms with DM_NVN_SKIP_MESH=1. So on this GPU the loop costs nothing measurable, and your M3 Pro gain could not be checked here. If you can, a run of main on your M3 Pro (after a shader rebuild for the new chain) would tell whether the store gives the same gain as your AND / OR; the reference entry is "Stage memory byte stores through a compare-and-swap loop" in docs/reference/shaders.md.