[nafields]

What and why

Symptom. With DM_NVN_RT_RECLAIM=1 (#1588), Ocarina of Time's command buffers failed with a GPU page fault at f3,677 and f4,851 in every run. The faults are in compute shader 9e6b00b050e30801, which samples through the texture pool.

Cause. tex_by_id's slow path (nvn_mtl.m) keeps an ID's cached view when cur == v || v.parentTexture == cur, with cur = treg_tex(rp).

• treg_tex is nil when the ID has no texture now: a texture gone and not made again, one that could not be made, or (with Render targets dead by overwrite are reclaimed (DM_NVN_RT_RECLAIM, off by default): Ocarina of Time's Kokiri load holds 1.1-1.2 GB of render targets instead of 3.5 GB #1588) a reclaimed render target.
• A cached view that is the base texture itself has no parent either. So nil == nil kept it and stamped it valid again.
• tex_fast_rid then gave the pool tables its resource ID after the host had released the texture and dropped its residency.

With the reclaim on, this happened about 60 times in a 5,000-frame run. It's main's code, not the reclaim's: main reaches the same nil whenever an ID's texture goes and isn't made again.

Change. The cached view is kept only when cur is non-nil. An ID with no texture drops its view, and its slot takes the typed zero texture an empty slot of that type gets.

Reference entry: A texture ID with no texture kept its cached view. The Ocarina note has a line for it.

Checked

• Game: Ocarina of Time (0400486024DEC000, v131072), M2 Pro 16 GB, reclaim on:

  Run	Faults	Pace
  Before, to f7,731	f787, f3,677, f4,851	7,731 frames in 202.75 s
  Fix, to f5,241, every texture the reclaim's trim released marked	f786 only; none handed back	—
  Fix, clean, to f7,750	f786 only	7,750 frames in 202.5 s

  • The fault at f786 has another cause and happens with the reclaim off too.
  • Reclaim counts were alike: 45,045 reclaimed and 30,833 dead-ID reads, against 45,895 and 30,525.
  • The picture wasn't compared: a dead ID now reads the typed zero texture instead of the released one.

• How it was found:

  • per-dispatch commits in the faulting frames named the shader;
  • turning the reclaim off cleared the faults;
  • an exact mark on every trimmed texture showed tex_fast_rid handing them back.
  • Ruled out on the way: the bind-time pointer site ranges (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, bounded to the table entry: still faulted) and texture reuse.

• Tests: make -C dm/host GAME=0400486024DEC000; make -C dm/host/tests GAME=0400486024DEC000 -j run; check_t_alias_takeover (28, 0 failed); check_t_image_alias (329, 0 failed); test_docs.py; docs_symptoms.py.

• Not run: scripts/regress.py check, since only Ocarina of Time is available here. Without the reclaim the path is rare, but this change reaches every game whose texture IDs outlive their textures.

Docs

• The finding is in docs/reference/rendering.md and the game note, 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 or the attachments

[seedds]

Landed unchanged as 0e4480d, with you as co-author. Thanks: the nil == nil diagnosis was exact.

Checked on main with Ocarina of Time (v131072): an A/B walk from a save through the village reached the path zero times, with the same red lines and pace as before. So on main the fix matters only when a texture ID outlives its texture, as you said. The faults it removes are the ones you showed with #1588's reclaim. The host tests pass.