[aksmith-git]

Ocarina of Time's pso_manifest.tsv gets 4,959 more rows (3,193 S, 1,579 R, 187 C). These rows stop the stutter the first time the camera looks around a new place on iOS.

What stalled

On iOS this game has no bundled pipeline archive, and its pipelines are built through the MTLDevice, so any render pipeline that no list names is built on the submit thread at its first draw. That takes 0.1-0.9 s per pipeline on an iPad Pro (M5), and the frame waits for it. In places already played, the iPad's own pso_user.tsv covers everything (a 31-minute Kokiri Forest session showed 0 ms of submit-thread pipeline builds). The next places a player reaches were not covered: with only the iPad's lists, Hyrule Field built 344 pipelines in play and the forest bridge built 362.

Task / mesh pipelines (foliage, shadows) also stalled in our tree. Main already records and prewarms them since bf420fd (#1368), so this PR has no code change. Every M row from the same runs is already in main's list.

Mac, before / after

Smooth 60, the same routes. Device list = the iPad's lists. Cold system cache.

route	pipelines built in play	frames >= 50 ms	>= 100 ms	worst
Hyrule Field	344 -> 0	17 -> 3	15 -> 2	749 -> 236 ms
forest bridge (Saria)	362 -> 5	17 -> 8	12 -> 5	1273 -> 385 ms
Lost Woods	7 -> 2	26 -> 5	9 -> 3	922 -> 174 ms
Kokiri Forest	8 -> 0	6 -> 9	4 -> 4	256 -> 257 ms

The "before" Lost Woods and bridge runs also include task / mesh builds of up to 907 ms (main already handles those, see above). The frames still over 100 ms are the load frame, the shot at the end of the run, and the bridge cutscene's own pipelines.

iPad

iPad Pro (M5), with these rows plus the mesh prewarm: the user called it "way way better". First-look stutter is gone except in the forest's heaviest GPU area.

How the rows were made

• iPad rows: taken from the iPad's own pso_user.tsv lists (93 lists, hours of play on v131072), keeping only rows this list lacked.
• Mac rows: recorded on a Mac with DM_PSO_RECORD, with the iPad's lists as the device list, so the recording holds only what those lists miss. Each run loaded a save and looked around: the forest bridge (Saria's farewell), Hyrule Field, the Lost Woods and Kokiri Forest. The Mac's render keys match the iPad's.
• Checks against main:
  • Every S / C key, and both shaders of every R row, are in shader_map.tsv with the right stage.
  • Every R row parses with main's pso_skey_parse, is already normalized, and duplicates no existing row.
  • The rows name shaders by content key, so they do not depend on the shader chain.

Cost: on a cold first start the prepare step also builds the added pipelines. The bundled list goes from 9,789 to 14,748 rows.

Tests: t_pso_skey OK; t_pso_warm 123/0 (Metal 4 and MTLDevice); t_nvn 277/0; test_docs, test_game_profile and test_pso_offline OK. Prepare time and play on main's chain (d403eb0683df) were not measured: the runs above used an older chain.

[seedds]

Landed unchanged on main as 47773ed (your commit, rebased). Thanks — the first-look numbers made the case.

Checked before landing: the 4,959 rows are a pure append with no duplicates; every S / C key and both shaders of every R row are in shader_map.tsv with the right stage; the 13 vertex-only R rows take the prewarm's no-fragment path. test_docs, test_game_profile, test_pso_offline, test_nsp_incremental and test_nsp_mac_app pass. No game was run here.

Still open, as the note says: the cold first start's prepare time on iOS with the added render pipelines has not been measured. If you get a fresh install's pipeline prepare: line from the iPad, it would be welcome here.