[Fasen24-AI]

What and why

How much memory the shared render targets of a game like Ocarina of Time could give back depends on two numbers the host did not log: the Metal memory those targets hold, and the guest storage they stand for once overlapping intervals are counted once. The memory line and restop sum allocated sizes, but several targets can sit in one family heap, and on NVN several descriptions overlap in the same pool bytes. So neither sum says what the targets need.

DM_NVN_TEX_BREAKDOWN=1 (off by default) makes DM_CTL restop log one [rtbreakdown] line per shared render target of a GPU-only or virtual pool: pool, offset, guest size, Metal format, sample count, the texture and its allocated size, its heap and whether it is a resolution family's, and the frame of its last recorded GPU write. The write stamp is kept apart from the lookup stamp, so a descriptor lookup does not count as a write. dm/tools/nvn_rt_breakdown.py <log> then reports:

• nominal texture bytes and distinct Metal allocation bytes;
• the union of guest intervals per pool, format and sample count, and what family heaps already cover;
• an estimate of the entries a newer write elsewhere has overwritten (NX2navi's rule), leaving out equal offsets, a writer inside the older range, unknown write times and targets written in the last two frames.

It changes no allocation or residency: it measures the opportunity, not a saving. Reference entry: Render-target allocation and guest storage census.

What I found with it on Ocarina of Time, on a branch that also carries #1453 and #1731, so not main's numbers: on the scripted Castle Town walk, at the peak, 3,950 MiB of distinct shared-target allocations stood for 841 MiB of guest storage. 469 MiB of the targets were already in family heaps. RGBA16F alone was 757 MiB against 37 MiB. The overwrite estimate at that snapshot was 666 MiB. So heaps per pixel format at the guest offset would reach more than the overwrite rule, at least on this walk.

On my branch the lines went to the texstat command of #1436; here they go to restop, which main has.

Checked

• Tests: make -C dm/gfx/tests GAME=0400486024DEC000 check_t_rt_breakdown, with the switch on and off, under Metal validation: only the enabled diagnostic stamps writes, finalizing the pool removes them, and the snapshot makes no pool buffer. test_nvn_rt_breakdown covers interval unions, allocation deduplication, overwrite exceptions and shared heaps. test_docs passes. The Mac host builds.
• Games run: Ocarina of Time (0400486024DEC000, v131072), on my branch, with the diagnostic on and off on the same host, one run each. Neither run had a 300-frame window over 17.5 ms; footprint 12,917 and 12,472 MiB. Not run on main: this game's shaders do not convert there since 0662f9d (Ocarina of Time (0400486024DEC000 v131072, Mac): 22,296 shaders fail to compile in Metal since 0662f9d, dm_blend0's main0_out& has no address space qualifier #2272).
• Devices: MacBook Pro M5, 24 GB, macOS 27.2.

Docs

• The finding is in its game note and its docs/reference/memory.md entry, and python3 dm/tools/docs_symptoms.py was run
• A chain tool changed (none)
• No game files, keys or data extracted from a game in the change or the attachments

🤖 Generated with Claude Code

https://claude.ai/code/session_014eD437mxrMnW2UwLZhpwc7