[scoofz]

What and why

Symptom. In The Legend of Zelda: Ocarina of Time (0400486024DEC000, v131072), the snowy areas showed black or dark 16×16 blocks, aligned to the screen grid, where the snow meets rock and walls: in front of the frozen walls, at the foot of pillars, on snowy stairs. The blocks moved every frame. Inside them, what lies behind the snow showed through, as if the snow had failed its depth test there. Nothing changed them: present upscaling off, render scale, docked or handheld, DM_NVN_SKIP_MESH=1, the fixed-resolution cut or not, DM_NVN_FB_SNAP=all, DM_NVN_UNWRITTEN_DC=0.

Cause. The snow draws (55845639d605e028, tessellated, and ee567dea65288f58, among others) test depth LEQUAL with depth writes on, and their fragment shader samples that same depth texture through a bound texture slot (a depth fade against what lies under the snow). Sampling an attachment the draw itself writes is undefined in Metal: on Apple's GPUs whole tiles of another state come back, the same failure as Same-pass feedback read through a snapshot for colour attachments (#377). NVN gives the draw the depth from before it. fb_prepare already ended the pass before such a draw when an earlier draw of the pass had read the depth, but the draw's own read of what it writes stayed undefined.

Change. General, in nvn_mtl.m:

• fb_prepare: a draw that writes depth while a fragment texture slot (fb_slot_reads, new) or a bindless handle (fb_texu_reads) names the depth attachment's storage asks for a depth copy, and the open pass ends.
• rp_begin_ex_: the pass that draw opens copies the depth attachment into a texture of the same format and size (g_dswap, kept between uses) and attaches the copy instead. The draw writes the copy and samples the original, which nothing changes until the pass ends.
• rp_end_at: the copy goes back into the depth attachment. A full barrier orders both copies with the passes around them (g_game_barrier).
• Only whole single-level 2D depth attachments that the pass does not clear. A request no pass with a depth attachment takes is dropped, not left for a later pass.
• Reads through the texture pool or a dynamic index are left out on purpose: they may name any texture, and Ocarina of Time keeps its depth textures in the pool every material shader reads (pool_ds_read); taking them would give many draws a pass and two copies each.
• DM_NVN_DEPTH_SWAP=0 turns it off.

Reference entry: A draw that samples the depth it writes. The game note has a line for it, and the symptom index is regenerated.

Checked

• Tests:
  • New dm/gfx/tests/t_depth_swap.m (make -C dm/gfx/tests GAME=<id> check_t_depth_swap), through the production fb_prepare, rp_begin and rp_end, with MTL_DEBUG_LAYER=1, once at the default and once with DM_NVN_DEPTH_SWAP=0. A draw writing depth whose texture slot names the depth takes the copy, and the depth it wrote reaches the attachment. A draw writing depth it does not read, and one reading depth it does not write, keep the attachment. A request no depth pass takes is not left for a later pass. 19 checks each, 0 failed.
  • check_t_feedback: 203 checks, 0 failed. One check, "two reports in one command buffer read two times", failed once on main without this change and passed in the run with it; it looks flaky and unrelated.
  • dm/tools/tests/test_docs.py and test_env_switches.py pass. The host builds (make -C dm/host GAME=0400486024DEC000 dmhost).
  • Not run: dm/tools/lint_c.py tidy (no clang-tidy 23 on this Mac).
• Games run: The Legend of Zelda: Ocarina of Time (0400486024DEC000, v131072), Mac, docked, around the snowy areas (the frozen walls and pillars, the snowy stairs).
  • How it was traced: DM_CTL texdump with DM_NVN_TEXSNAP copies of the 1536×864 RG11B10F scene after each pass. The blocks appeared in the passes of 55845639d605e028 and ee567dea65288f58, one draw each, each pass ended by fb_prepare before it. A temporary switch that turned those two shaders' depth writes off removed the blocks where they draw, and not where other snow draws.
  • With this change, the blocks are gone everywhere checked by eye. The log shows the copy in use (depth read while written: …), no new [RED] line, and a frame time p50 of 16.6 ms in the area (300-frame windows). That is not a matched A/B.
  • The run was on a tree with other local changes (main 7f50222 plus open PRs Raw global memory through a pointer read when the draw is bound: the host fills each fixed-offset pointer's pool range before the draw (chain 1ffcb6b77740) #1585 and Add a render-scale ceiling for Ocarina v131072 #1497); this branch is the change alone on current main.
• Devices and OS: MacBook Pro M3 Max, macOS 26.7.2.
• Regression: not run. regress.py check needs games this Mac does not have beyond Ocarina of Time. The change only acts on a draw that writes depth while a texture slot or bindless handle of its fragment shader names that depth, which was undefined on Metal before; every other draw takes the same path as before.
• Cost: a pass of its own and two copies of the depth for each such draw (about 6.6 MB each for a 1536×864 depth-stencil). In Ocarina of Time's snowy areas that is about ten draws a frame.

Docs

• The finding is in docs/reference/rendering.md and the game note, and python3 dm/tools/docs_symptoms.py was run (the symptom index)
• No game files, keys or data extracted from a game in the change or the attachments

🤖 Generated with Claude Code

[scoofz]

Closing: #1917 (merged in 8190693) handles the same case: a draw that writes depth and samples it through a texture slot now reads a copy. That covers the snow draws here (55845639d605e028, ee567dea65288f58). The snow area could not be checked again in game. If the black 16×16 blocks come back, I'll reopen with a capture.

[seedds]

Thanks for tracing this down to the snow draws. Main now covers them another way, so I'm closing this PR without landing it:

• 8190693 gives a draw that writes depth and samples it through a texture slot a copy of the depth, taken at the first such draw since the game's last barrier and reused without ending the pass (issue Ocarina of Time (0400486024DEC000 v131072, M3 Max): square holes on an 8×8 grid along snow edges in adult Zora's Domain; the snow draws sample the depth attachment they write in their own Metal pass #1932's design, PR A draw that writes depth and samples its own depth attachment reads a copy of it: Ocarina of Time's light-blue dashes over the rock at Death Mountain Trail's cave entrance are gone #1917). 55845639d605e028 and ee567dea65288f58 read the depth through texture slot 6, as plain texture2d bindings (no pool or handles), so they take this path.
• This PR's swap gives every such draw a pass of its own and two full depth copies. In adult Zora's Domain, about 145 such draws a frame, Ocarina of Time (0400486024DEC000 v131072, M3 Max): square holes on an 8×8 grid along snow edges in adult Zora's Domain; the snow draws sample the depth attachment they write in their own Metal pass #1932 measured the copy reused until a barrier taking GPU p50 from 25 to 15 ms against one-draw passes. Reuse is allowed because NVN only promises the newer depth after a barrier.
• b54968e lands a clear still waiting for the draw's pass before the copy is taken.

The storage-overlap match (tex_storage_overlap) would matter if a game samples its depth through a different texture object over the same memory. Nothing shows that here, since #1932's pass dump has the same serial on the slot and the attachment, but tell me if you find such a case.

Could you retest the frozen walls, pillars and stairs on current main? If the blocks are still there, please open an issue with the spot and a pass dump.