[socram03]

What and why

A depth-writing draw that samples its own depth attachment can still read stale depth after #1917. OP_CLEAR_DS records a full clear for the next render pass, but fb_depth_snap can copy the attachment before that pass opens: store 0.75, record a clear to 0.375, then draw, and the snapshot still contains 0.75.

Apply pending depth/stencil clears through rp_flush before taking a fresh snapshot. Existing snapshot reuse and the depth-read rule stay the same. The real-depth fixture now covers pending clears for Depth32Float and Depth32Float_Stencil8, both with a colour attachment and in depth-only passes. All four new cases fail on main before the fix.

The game note also records an independent Ice Cavern diagnosis on M5: the affected materials sample their own depth at slot 6, and I confirmed in play that a depth snapshot removed the dark blocks. The general depth-feedback fix is already upstream; this patch contributes the remaining clear-ordering case.

Checked

• check_t_feedback: 273 checks, 0 failed with Metal validation; 4 failures before the fix.
• make -C dm/gfx/tests -j3 GAME=0400486024DEC000 run: passes, including every graphics test in the run list and the pull/TBDR fixtures.
• Host build succeeds. clang-tidy LLVM 23.1.4: no findings above the existing baseline; docs/env-switch checks: 7 tests pass.
• Device: Apple M5, macOS 27.0.1, Xcode 27.2.
• Gameplay evidence: Ocarina of Time (0400486024DEC000, v131072), Ice Cavern, using the independent local depth-snapshot host on 3b6b9803 / chain 39417042cfe8. Current main plus this patch has not been played.
• regress.py impact reaches NVN users (Breath of the Wild, Pokémon Scarlet and Tears of the Kingdom have usage manifests). regress.py check was not run: only Ocarina of Time is available locally, and its installed shaders use the older chain above. Other games and iOS remain untested.

Docs

• The finding is in the rendering reference and game note; docs_symptoms.py was run.
• No game files, keys or data extracted from a game in the change or attachments.

[seedds]

Thanks for this, and for the failing cases. Main already has the same fix, so I'm closing this PR without landing it:

• b54968e calls rp_flush before both snapshot copies, the depth copy in fb_depth_snap and the colour snapshot in fb_prepare. A clear still waiting to be the next pass's load action is applied first, so the copy holds the cleared content. It came from the patch in 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, posted before this PR, and is credited to its author.
• t_feedback covers what your new cases do: real Depth32Float and Depth32Float_Stencil8 copies with the clear still waiting, in a colour pass and a depth-only pass, plus a colour snapshot. 6 of those checks failed before b54968e.

Your Ice Cavern finding on the M5 is useful, but it was seen on a different host build. If the dark blocks still show in the Ice Cavern on current main, please open an issue with the spot and a pass dump (DM_CTL passdump 1), and I'll add it to the game note.