[enjoyerofslop]

What and why

Symptom: while a game makes many textures, frames take hundreds of milliseconds and up to a second, all of it in submit+present (the [longframe] lines). A sample of the process names alias_take_over the submit thread's hottest function. Found in The Legend of Zelda: Ocarina of Time's cutscenes (Switch 2, 0400486024DEC000).

Cause: when a new shared texture takes over storage, alias_take_over (dm/gfx/nvn/nvn_mtl.m) checks each sharing-table entry it could remove. For each one it asked whether a live texture object still resolves to it with serial_holds(&g_by_serial, ...), a walk over the serial table's whole capacity. With about 7,500 serials and thousands of shared textures, every new shared texture walked the table once per overlapping entry. The disassembly puts the hot samples (alias_take_over+452..468) in that inlined walk. Ocarina of Time's texture-pool walks make hundreds of textures in one submission, each of them going through it.

Change: a count per object of the serial-table entries that hold it (g_by_serial_held). It is kept by every writer of the serial table: serial_put, serial_del, tex_put (when it writes the live table) and the upgrade's in-place replacement. alias_take_over now asks it in one lookup. An entry holds its object (CFBridgingRetain), so a counted address cannot be reused while it is counted. A slot written past these helpers (only t_upgrade_alias does that, to fill the table) is never counted, and taking it away leaves the count alone. The rule alias_take_over applies is unchanged.

Reference entry: A storage takeover walked the serial table for each entry, next to the takeover's own entry. The symptom index is regenerated. The entry also records what is still open: in that game the textures themselves are made again and again (84,000 to 103,000 storage takeovers in about 200 s of play), which I am looking into separately.

Relation to other PRs: independent of #1428 (pool tables), which touches other functions of the same file. #1299 reworks serial_put, serial_del and tex_put. On it, the same held_add calls go beside its own lines; that is how the Ocarina of Time host below was built.

Checked

• Tests:
  • make -C dm/gfx/tests GAME=01007EF00011E000 t_alias_takeover: 28 checks OK. It covers:
    • an entry a live object resolves to stays;
    • one nothing resolves to goes after ALIAS_IDLE submissions;
    • two serials naming one object keep it held until both go;
    • replacing a serial's object moves the count;
    • a timing check: a takeover past 1,000 held entries with 20,000 serials in the table takes 0.025 ms. With the old walk in that one line, the same test took 4.3 ms, so the check is set at under 1 ms.
  • t_upgrade_alias (13), t_copy_alias (101), t_srgb_alias (8), t_image_alias (318) and t_cpu_tex (56) pass.
  • make -k -C dm/gfx/tests GAME=01007EF00011E000 run: every test passes but t_nvn. It aborts in up_owner_check ("up_begin called on thread ''", from present_enqueue), and it aborts the same way on main (865cc35).
  • python3 -m unittest dm/tools/tests/test_docs.py: OK.
• Games run: The Legend of Zelda: Ocarina of Time, 0400486024DEC000, update v131072, with [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, Kokiri Forest through Saria's cutscene, M5 Max.
  • Captures: 60 s sample captures of the process over the cutscene. Before, alias_take_over took 2,277 of the 3,711 samples the submit thread spent making textures (tex_mtl_), 61 %. After, it took 38 of 618, 6 %, so each texture creation costs less than half as much.
  • Before the change: in the first capture, 88 % of the gameplay long frames were host CPU in submit+present, and this function was the largest single part of it.
  • Game runs: the runs are on the wall clock, because the game does not run under DM_DETCLOCK. The cutscene's heaviest part lands inside some 250 s runs and outside others. In the runs that reached it, frames over 100 ms went from 101 and 102 to 58, and their total from 27 and 28 s to 19 s. One run with the fix is too few to call that more than a direction.
• regress.py: python3 scripts/regress.py check --baseline 865cc35f --candidate HEAD --games 01007EF00011E000,0100000000010000 (the full run). regress.py impact lists Breath of the Wild among the games that reach the serial table.
  • Saves: as in Pool tables for texture handles traced to no slot reuse their buffers and pass over IDs of another type #1428, the routes ran from this contributor's own saves, because the profiles' saves/outdoors and saves/look_around are not on this Mac. Breath of the Wild waits at the load prompt (frame 2500 is not reached, in the baseline too), and Odyssey plays its opening from a new game.
  • Screenshots: the check compares against one baseline run (noise 0). Measured with regress.py's shot_hashes / shot_distance against five runs of 865cc35:
    • Breath of the Wild, 60 s (the title's slideshow): the baseline runs differ by up to RGB 26.8 and 28 dHash bits, and the candidate is within RGB 15.3 / 16 bits of one.
    • Odyssey, 95 s (the opening cutscene): baseline runs differ by up to RGB 14.9 / 9 bits, and the candidate is within RGB 4.2 / 6 bits of one.
  • Everything else is unchanged: shaders, frames reached, frame rate, footprint and prebuild.

regress.py check (full): REGRESSION

Baseline 865cc35f 865cc35, candidate HEAD 4599612; Apple M5 Max, macOS 27.0.1, Xcode 27.2; 490.9 s

game	status	shaders (base → cand)	newly failing	newly building	changed MSL	interface (new / known)	boot	fps p50	frame p99 ms	peak MB	prepare s	new RED
The Legend of Zelda Breath of the Wild 01007EF00011E000	CHANGED	19420/19420 → 19420/19420	0	0	0	0 / 0	FAIL	29.5 → 29.8	91.83 → 69.23	3057 → 3050	1.49 → 1.42	0
Super Mario Odyssey 0100000000010000	REGRESSION	27984/27984 → 27984/27984	0	0	0	0 / 0	ok	59.9 → 59.9	18.63 → 18.37	2359 → 2359	None → None	0

The Legend of Zelda Breath of the Wild 01007EF00011E000: CHANGED

• CHANGED: screenshot at 60 s moved (RGB 19.53)
• known (baseline too): frame 2500 not reached by 60 s (max 3216)
  • screenshots (s: dHash bits / RGB diff / baseline noise): 60: 1/19.53/0, 80: 3/1.55/0
  • baseline: exit None, first frame 2.9 s, max frame 3189, reached False, prepare 1.49 s, prebuild 90.7 s (15631 built, 0 failed), fps 29.5, p50/p99 33.35/91.83 ms, peak 3057 MB
  • candidate: exit None, first frame 2.6 s, max frame 3216, reached False, prepare 1.42 s, prebuild 87.6 s (15631 built, 0 failed), fps 29.8, p50/p99 33.36/69.23 ms, peak 3050 MB
  • time: chain 28.9 s, smoke 198.3 s

Super Mario Odyssey 0100000000010000: REGRESSION

• REGRESSION: screenshot at 95 s differs (dHash 12 bits, RGB 14.82)

  • screenshots (s: dHash bits / RGB diff / baseline noise): 70: 2/1.21/0, 95: 12/14.82/0
  • baseline: exit None, first frame 1.3 s, max frame 6520, reached True, prepare None s, prebuild 135.8 s (32864 built, 0 failed), fps 59.9, p50/p99 16.66/18.63 ms, peak 2359 MB
  • candidate: exit None, first frame 1.1 s, max frame 6515, reached True, prepare None s, prebuild 129.4 s (32864 built, 0 failed), fps 59.9, p50/p99 16.66/18.37 ms, peak 2359 MB
  • time: chain 23.5 s, smoke 240 s

• Devices and OS: M5 Max (Mac17,6), macOS 27.0.1.

Docs

• The finding is in its docs/reference/rendering.md entry, 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

[jonpage0]

Measured on an M3 Max (36 GB, macOS 27.0.1, Xcode 27.2), Ocarina of Time v131072, running (not a cutscene): the same scripted run through Kokiri Forest, from the Kokiri balcony autosave, driven by DM_CTL, with the pipeline archive already warm (no new pipelines, no texture uploads after the load), one run per host, no sampler:

122 s of running, three legs	without	with this change
frames over 100 ms	85	2
frames over 200 ms	31	0
frame p95 / p99	41 / 151 ms	22 / 29 ms
submit-thread CPU p95 / max	34 / 391 ms	10 / 63 ms
[longframe] lines, of them submit-dominated	419 (290)	79 (65)
fps	46	54

What the sample captures said before the change (30 s legs, the game's Presentation Thread, which calls nvnQueueSubmitCommands): 77–79 % of the thread in mtl_exec; pool_gpu 27–33 %; tex_mtl_ 12–16 %, of which alias_take_over 11–15 % of the whole thread (serial_holds 7–10 %). So in plain running the pool walk's texture creation was almost entirely this walk. Legs 2 and 3 with the change had no frame over 50 ms at all. Picture unchanged at the same spot.

One note for whoever lands this on a tree with #1404's serial_holds (the version that also walks texture views' parents and a packaged texture's tex/view/spare): the count has to be kept for those holds too, or a takeover can retire a parent a live view still reads. I kept that on my tree with the same held_add at the four writers plus a held_member at the three places a packaged texture's members change (sparse_view, the re-upload, the upgrade); the test's two extra cases (a view holding its parent; a member move) pass. Happy to share that diff if it helps.

[seedds]

Landed as d4239a6, rebased onto main with your design and code unchanged (credited as co-author). Your second commit was not needed: main already has that t_int_float_view fix (#1338).

What I checked on an M4 Pro, Ocarina of Time loading a Kokiri Forest save, through Saria's dialogue and a walk through the village:

• A host that asked both the count and the old walk at every takeover compared them 393,216 times and they never differed, so the takeover makes the same choices as before.
• Main's host against this one, one run each: [longframe] lines 332 → 212, frame p99 72.8 → 38.8 ms, same red lines. Both hosts were built at 88c7e03 to match the build's shader chain.

One addition to the reference entry, after the note from jonpage0 (thanks for the M3 Max numbers): a change that lets a live object hold a shared texture another way (#1404's views and packaged members) must count those holds too. Whoever lands #1404 needs to carry the count there.