[lunks]

What and why

In Ocarina of Time (Switch 2, 0400486024DEC000, v131072; profile in #1299) about 70 render passes a frame end in fb_prepare for no reader, as @PucaVaz found and measured in #1385 and #1396: a pool or dynamic-handle fragment shader could name the depth attachment, only the GPU knows, so fb_prepare takes it as a depth reader and the next draw that writes depth ends the pass. The game's material shaders are pool shaders that write depth, so each draw ends the pass the one before it opened. Asking the pool tables does not help (#1396): the game registers its depth texture in the pool those shaders read.

Change: a pool or dynamic-handle draw that writes depth itself is no longer taken as a reader of it (S.ds.dt && S.ds.dw): sampling the attachment you are writing is a feedback loop, undefined on the console too. Pool draws that leave depth alone still count (water reading the scene's depth), as do real slots and TEXU handles. DM_NVN_FB_DSELF=0 counts them as before; ab alternates with DM_AB. It is on by default; say so if you would rather have it opt-in.

Evidence, and how far to trust it:

• In Kokiri Forest the reader wrote depth itself in 67,730 of 67,739 splits, from 32 shaders (91% of them on one 128x128 target, in bursts of up to 600 passes a frame).
• A/B outdoors (author's stack, Apple M5 Pro, 1280x720, game upscaler, encoding thread off, 6 paired phases): passes 183 to 112 a frame, attachments 286 / 316 to 244 / 273 MB (load / store), GPU p50 20.3 to 16.5 ms, frame p50 20.7 to 16.8 ms.
• The rule is inferred from counters and from the API, not proved for any shader. The picture was checked only coarsely. No other game was run, and this branch itself was not played (it needs [WIP] The Legend of Zelda: Ocarina of Time (Switch 2, 0400486024DEC000, v0, SDK 22.2.8) runs on the Mac through the title movie into Kokiri Forest #1299's profile).
• A shader that reads the depth it also writes would break under it. The snapshot approach in Ocarina of Time: about 74 of 178 render passes a frame end in fb_prepare, and every texture pool shader counts as a depth reader #1385 (depth taken where the pass would have ended, @deanpektas27 and PucaVaz) would not, so it is the sound one and this is the cheap one for a game whose draws never read what they write. It also does not need the pool walk, so it does not depend on Passes ended for same-pass reads are counted by cause, and a pool shader can count as a depth reader only when its tables can hold the depth storage (DM_NVN_FB_DPOOL=1, opt-in) #1396.

Stacking on #1396: that draft turns the line into g_fb_dread = fb_depth_reader(fs), so the two conflict in nvn_mtl.m (git merge-tree: that line, plus the generated docs). With #1396 merged first, the rule goes inside fb_depth_reader, on its dynamic and pool branches: int self = S.ds.dt && S.ds.dw && fb_dself();, then if (fs->rf.dyn && !self) and if (fs->rf.pool && !self). It must not be an early return 0 before them: that would also skip the final fs->rf.bindless && fb_texu_reads(...) check, which keeps a TEXU handle that names the depth a reader (found by @deanpektas27 when stacking the two). With both in, #1396's t_fb_dpool needs a pool draw that leaves depth alone for its cases, as every pool draw in it writes depth now. I will rebase this onto whichever lands first.

Reference entry: Pool shaders that write depth taken as depth readers. The symptom index is regenerated.

Checked

• Tests (Apple M5 Pro, macOS 27, niced; make -C dm/gfx/tests GAME=010015100B514000 check_t_feedback): 176 checks, 0 failed. New case depth_self_case: pool draws that write depth stay in one pass; a pool draw that leaves depth alone counts as a reader and the next draw that writes depth ends the pass; with the rule off a pool draw that writes depth counts as before. With the change taken out of fb_prepare, 3 of its checks fail. test_docs.py, test_env_switches.py and test_gfx_tests_makefile.py pass; docs_symptoms.py --check current; lint_c.py tidy on nvn_mtl.m and t_feedback.m: 0 file/check pairs above the baseline.
• Games run: none for this branch (the numbers above are from the author's stack, which carries the same change).
• Not run: the rest of make -C dm/gfx/tests run, the host tests, regress.py, any game on main. The rule applies to every game with pool or dynamic-handle fragment shaders that write depth; only Ocarina of Time is known to have them.
• Devices and OS: Apple M5 Pro, macOS 27.

Docs

• The finding is in docs/reference/rendering.md and python3 dm/tools/docs_symptoms.py was run
• No chain tool changed
• No game files, keys or data extracted from a game in the change

[deanpektas27]

Played on a branch that has #1299's profile, since this one can't be run alone.

Setup: Apple M3 Max, 36 GB, macOS 27.0.1. Ocarina of Time v131072 from a NUP, Mac build, windowed (2560x1440 window, 1536x864 scene), Kokiri Forest autosave. The branch is main (865cc35) + #1299 + #1360 (merged onto #1299's hints) + other open Ocarina PRs, with #1396 and #901, then this PR's commit 5cb7d71 cherry-picked on top. I didn't merge the PR because its base would have brought in main's newer alias-region and audio commits.

A/B: DM_NVN_FB_DSELF=ab DM_AB=300, standing still outside on the path into the village. Medians of 7 paired phases (phases 4–17, 225 frames each):

	rule off	rule on
passes a frame	184.6	114.1
GPU p50 / p90	29.43 / 33.42 ms	23.93 / 25.02 ms
frame p50 / p90	29.68 / 33.53 ms	24.08 / 25.50 ms
attachments a frame (load / store)	390 / 395 MB	332 / 337 MB

Every pair moved the same way: GPU p50 5.2–6.0 ms lower. The p90 drops by about 8 ms, so the frame pacing is steadier too. #1396's by-cause line in an earlier run on the same branch had 59.8–74.4 depth splits a frame after pool or dynamic shaders, and 0.0–0.1 for every other cause.

Picture: one screenshot with DM_NVN_FB_DSELF=0 and one with the default, from the same spot on that path (fog, light shafts, grass, foliage edges, stone path, shadows, NPCs at a distance). I see no difference apart from the falling leaves and a fairy, which move anyway. This is a visual comparison, not a pixel diff, and the camera angle differs slightly. No GPU errors in any of the runs.

Rule off (DM_NVN_FB_DSELF=0, HUD GPU 29.1 ms):

Rule on (default, HUD GPU 25.5 ms):

Stacking on #1396, two notes:

• I put the rule inside fb_depth_reader as int self = S.ds.dt && S.ds.dw && fb_dself();, then if (fs->rf.dyn && !self) and if (fs->rf.pool && !self), rather than an early return 0 before the pool branch. The early return would also skip the fs->rf.bindless && fb_texu_reads(...) check at the end, which this PR's own line keeps for a TEXU handle that names the depth.
• With both in, Passes ended for same-pass reads are counted by cause, and a pool shader can count as a depth reader only when its tables can hold the depth storage (DM_NVN_FB_DPOOL=1, opt-in) #1396's t_fb_dpool fails 9 of 49 checks, because every pool draw in it writes depth (S.ds.dt = S.ds.dw = 1), so the new rule exempts them. Setting g_fb_dself_m = 0 at the top of its test makes it 49 of 49. Whichever of the two lands second needs that line. check_t_feedback passes (180, 0 failed).

[lunks]

Thanks, a second machine and a bigger scene is what this needed. You are right about the early return: the rule belongs inside fb_depth_reader on the dyn and pool branches, as you wrote it, so the TEXU check at the end still runs. I corrected the stacking paragraph in the description. t_fb_dpool needs a pool draw that leaves depth alone for its cases, which is for whichever lands second to carry.

[bettterlabs]

A third machine, a 16 GB one where the GPU is the limit: Mac mini M4, macOS 27.2, docked (2048x1152 scene in a 2560x1440 window), v131072. In earlier powermetrics samples during play, the GPU held its top clock (1,578 MHz) and was about 97% busy. Host only: david-on-spring's #1386 branch (562c1f4 on f3ac5ea, chain 84aede056dea) + #1396 + 5cb7d71, with the rule inside fb_depth_reader as deanpektas27 describes.

DM_NVN_FB_DSELF=ab DM_AB=600, camera still. Medians of the phases that fall wholly inside the still stretch:

	outdoors, off (3)	outdoors, on (3)	Link's house, off (2)	Link's house, on (2)
passes a frame	178.6	105.8	181.8	109.2
GPU p50 / p90	44.8 / 53.1 ms	35.6 / 38.1 ms	42.7 / 64.6 ms	32.4 / 56.7 ms
frame p50 / p90	32.3 / 35.8 ms	26.7 / 27.7 ms	41.3 / 60.8 ms	25.9 / 47.4 ms
attachments a frame (load / store)	318 / 328 MB	309 / 318 MB	306 / 334 MB	288 / 316 MB

That's about 31 → 37 fps outdoors (in Kokiri Forest, by a chest) and 24 → 39 fps in the house. Attachment traffic drops by only 9–18 MB a frame here, against 58 on the M3 Max and 42 on your M5 Pro, so on this M4 most of the gain doesn't come from attachment traffic.

Picture, as a pixel diff. In Link's house, DM_NVN_SHOT took a pair of screenshots 15 frames before and 15 frames after each switch of the rule, with the camera unchanged. The four pairs from the still stretch differ by a mean of 1.6–3.5 levels (0.6–2.1% of pixels by more than 32). Two shots under the same rule 570 frames apart differ by 2.8–4.5 (1.7–2.8%). Amplified, the pairs differ only where something moves: Link's idle pose, Navi, grass and leaves. Walls, bed, curtain and lamps match.

Both runs logged only the REDs this build always logs (the title movie's AV1 packet; slot 7's texture type mismatch). No GPU errors, and both exited cleanly.

Drafted with Claude; reviewed by me.

[PucaVaz]

I ran this PR's rule against the snapshot follow-up to #901 that I'd been building (pool draws read a copy of the depth attachment through their pool tables instead of ending the pass), in one process: Ocarina of Time, Link's house, docked, MacBook Air M4, DM_AB=600 with the phases cycling through today's rule, DM_NVN_FB_DSELF and the snapshot. 14 phases each:

per frame	today	DSELF	snapshot
render passes	175.3	103.2	104.9
passes ended in fb_prepare	72.1	0.0	0.0
depth copies	0	0	2.75
attachments load / store (MB)	446 / 461	406 / 420	422 / 436
frame p50 / p95 (ms)	35.97 / 42.19	30.22 / 32.44	30.80 / 33.10
GPU span p50 / p95 (ms)	36.50 / 43.23	30.52 / 34.51	31.11 / 34.80

Paired against the neighbouring phases of today's rule (frame / GPU span p50): DSELF −5.61 / −6.06 ms, the snapshot −4.98 / −5.45 ms. Snapshot minus DSELF: +0.68 / +0.65 ms. A second, throttled run gave the same order (DSELF −5.86 / −5.87, snapshot −4.90 / −4.62). In this scene the snapshot buys nothing over this rule and costs copies and table builds, so I'm not opening it.

Do the draws read the depth they write? In my runs the passes end between material draws that write depth into a 128×128 Depth32Float target (222 of 227 in a window of 400 passes), each after a reader that wrote depth itself, which matches your 67,730 of 67,739 and @deanpektas27's 128×128 count. A diagnostic build read every 32-bit word of the uniform and storage buffers bound to every pool draw with a depth attachment as a texture handle, in windows of about two frames. For the 128×128 target (220–225 such draws a window, all writing depth, about 3.2 GB scanned) no word named either of its two pool IDs, in 3 of 4 runs; in the other run 24 words a window matched its IDs that time (0x201c, 0x201d) and I didn't capture where. The remaining few splits are on a second 1920×1080 Depth32Float target, drawn by the shadow-receiving materials (fa20be590aae1d99, 74a006f0005b2f7a, e2f868a2799ed178, the family of dbda7678a92ef6e5): a handle naming it sits in their fragment storage buffer 0, but all 138 of their pool reads take their handle from the light records in storage buffers 1 or 2, which hold none. So, within what a CPU scan can see (handles computed on the GPU, or written by it after the scan, are not covered), these draws don't read the depth they write. dbda7678a92ef6e5 itself didn't draw in Link's house in any of my runs.

Picture. Screenshots at frames 4,800, 5,400 and 6,000 at a fixed render scale (DM_UPSCALE_RATIO=1.5), same save and presses. DSELF against today's rule: mean difference 4.8–5.5 levels, 3.7–4.2% of pixels by more than 32. Two runs of today's rule against each other: 5.2–7.9 and 4.0–6.1%. The differences are Link, Navi, leaves, grass and the dust in the light, as between any two runs.

Drafted with Claude; reviewed by me.

[seedds]

Thank you, your numbers independently confirmed the cause. Main took a different rule (a shader counts as a depth reader only once a depth texture was seen read through a pool, 6121fd7), as yours assumes a shader never reads the depth it writes. A counter now shows if a later area needs your condition too; if it does, this is the idea to revisit. Final checks on the rebased tree (full shader build, walks, regression) are still running, so please report anything you see.