[dean0396]

What and why

On main, Ocarina of Time compiles a native task / mesh pipeline at its first draw when no prewarm list names it (Native mesh pipelines compiled at their first draw). This PR adds 171 M rows that main's pso_manifest.tsv doesn't have. It changes data only.

• 166 rows are behind the task shader a5288d0a6c4971fd_b. The other 5 are behind b43c34b2a11c2142_b (2), efaa4fa6a80ba719_b (2) and 2d3240242e2ec411_b (1).
• I recorded them on my M3 Max (macOS 26.7.2) on v131072, in a sweep of 33 areas and in long play sessions. The recording host was a fork that writes the same M rows: the key without the border field, 1,008 hex characters, like main's 164 rows. The fork's pso_skey layout is main's minus the two border words at the end.
• One of them (task a5288d0a6c4971fd, mesh 53dc93ba404ae78c, pixel 1ac5c1ed2feed1bc) froze adult Zora's Domain for 824 ms at its first draw on that fork. The fork builds mesh pipelines differently from main, so that number doesn't carry over to main.
• Following Ocarina of Time's prewarm list gets 41 more task / mesh pipelines from later play #2083, the rows go at the end of the file and one # line goes after the existing header lines. The game note's count goes from 164 to 335 M rows.
• No S, R or C rows. The fork's lists have many more that main lacks, but a longer list lengthens a cold first start's prepare step (Ocarina of Time prewarm rows recorded on an iPhone 18 Pro Max (from HookLink) #2017 notes that the 9,789-row list from PR 1488 prepared 16 s longer on a MacBook and avoided little).

Overlapping PRs:

• Ocarina of Time's prewarm list gets 15 more task / mesh pipelines recorded on a MacBook M1 #2280 (15 M rows from a MacBook M1). 14 of its 15 rows are in my recordings too. I left them to that PR, so the two don't share a row. Both append at the end of the file, so whichever lands second needs a trivial rebase. It also changes the same count in the game note.
• Build native mesh pipelines before their first draw (DM_NVN_MESH_PREDICT): mid-play stalls in Ocarina of Time #2307 (mesh pipelines built in the background when the game sets a program's shaders). It adds no rows, but it covers much of the same ground. It is on by default only on Macs with more than 16 GiB, so these rows still matter at or below 16 GiB and on iOS. With both merged, Build native mesh pipelines before their first draw (DM_NVN_MESH_PREDICT): mid-play stalls in Ocarina of Time #2307 treats a listed task / mesh / pixel triple as known and doesn't predict it, so these 171 pipelines would be built in the prepare step instead of in the background. Build native mesh pipelines before their first draw (DM_NVN_MESH_PREDICT): mid-play stalls in Ocarina of Time #2307 also takes its pass states from the lists' M rows: these 171 add one to the 8 that main's rows use (it keeps up to 16).
• feat(oot): complete 100% shader compilation, stabilize dynamic resolu… #1898 carries 13 of these rows, byte for byte, among its larger changes. If both land, the host reads each repeated line once (warm_parse skips a line it has already seen).

Checked

• Rows, against main at 084f5aa. I used a small program built on main's nvn_pso_skey.h and a script that reads main's shader_map.tsv the way shmap_read does:
  • all 171 parse with pso_mesh_skey_parse;
  • each row is byte for byte its own normalized form (the parse re-serialized, apart from the 16 border characters);
  • none is on main already, and none repeats another (compared by task key and normalized key);
  • every task, mesh and pixel key is in shader_map.tsv with stage task, mesh and pixel, and none has two stages there;
  • none is among Ocarina of Time's prewarm list gets 15 more task / mesh pipelines recorded on a MacBook M1 #2280's rows;
  • none uses advanced blending, so main's newer adv_dst_free bit (0 in these rows) doesn't change their meaning;
  • they carry no border field, so main reads them as border 0, the pipeline without the border corrections. Ocarina's game note says no sampler of this game needs a border twin, so that is the key main draws them with.
• Tests, all passing on this branch:
  • python -m unittest on dm/tools/tests/test_docs.py, test_game_profile.py, test_pso_offline.py and test_nsp_incremental.py;
  • t_pso_skey and t_shmap_warm, from make -C dm/gfx/tests GAME=0400486024DEC000;
  • the Mac host builds.
  • None of these tests reads Ocarina's list itself (t_shmap_warm, test_pso_offline and test_nsp_incremental write their own lists), so the row checks above are what checks the data. The rest of the GPU suite wasn't run: nothing here is code.
• Games run: none on main. At 084f5aa, main's Ocarina shaders don't compile with this Mac's Metal (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), so I couldn't do a cold first start. Main's newer 8fb5ffe makes the thread main0_out& change that 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 asks for, but I haven't rebuilt the shaders with it. That means neither the stalls these rows avoid nor the prepare step's added time is measured. For a sense of the cost: Ocarina of Time's prewarm list gets 41 more task / mesh pipelines from later play #2083's 41 rows added about 2 s to the prepare step on an M4 Pro. If it scales, 171 rows could add 8 to 9 s to a cold first start. I'd rather someone who can run main measured that before this is taken.
• Not checked: whether each mesh shader is drawn with a task. The host checks that (mesh_notask) against the built library while it prewarms, and skips a row that doesn't fit. 70 of the 104 mesh shaders here aren't in main's current rows. iOS wasn't checked either.
• Devices and OS: M3 Max, macOS 26.7.2 (recording only).
• regress.py check: not run. Only Ocarina of Time's list changes, and no code does.

Docs

• The finding is in its game note (the M row count under "Found on this game"). No reference entry or symptom index change.
• No game files, keys or data extracted from a game in the change or the attachments (shader keys and pipeline state only, like the rest of the list)