[oliverames]

What and why

Mario Kart World's profile ships no prewarm list (pso_manifest.tsv is the two-line placeholder), and its note lists "first-use pipeline compiles" under Open. On an iPhone that means every pipeline of a first race is built at its first draw. On my iPhone Duo, the first Grand Prix race from an empty list had 115 frames of 50 ms or more in 7,800, the worst 3.9 s, with 381 pipelines or shader libraries built inside them.

This PR fills the file with the phone's own pso_user.tsv after about 15 launches of one route: the boot, the title, the menus into a Grand Prix, then Mario Bros. Circuit with 24 racers and 5 to 8 minutes of driving. It's 9,342 rows in first-use order.

Kind	Rows
S (shader)	5,689
R (render pipeline)	3,492
C (compute pipeline)	150
M (task / mesh pipeline)	11

With the list at 9,418 lines on the phone, the same race had 23 frames of 50 ms or more in 28,700 (the worst 378 ms), and 3 of them built a pipeline (6 pipelines in all).

Two things about the rows:

• 3,316 of the R rows were written by an older host, from before attr_hi, so they were 880 hex digits long. I padded them with zeros to the current 1,008, which is what pso_skey_parse does when it reads a short row, and dropped the 98 rows that were then the same as a newer one.
• The list was recorded on 1.8.0. 21 of its 5,689 shader keys and 7 of its 150 compute keys aren't in the base game's shader_map.tsv, so a base-game build drops them at load, as the docs describe for a list from another version.

The game note gets the numbers in its Shaders section, and its Open line now says what the list covers. Its mesh draws line is rewritten too: main has native task and mesh pipelines since bf420fdae, and update 1.8.0 on the Duo built 11 of them, the list's M rows. That line also says the profile leaves pso_mtl4 off, so on an iPhone a draw whose pipeline isn't built waits for it. I'm testing that separately and will send it as its own PR if it holds up.

Checked

• Tests: test_pso_offline.py, test_game_profile.py, test_nsp_incremental.py, test_nsp_mac_app.py, test_docs.py and test_env_switches.py pass. I also checked the rows with a script: every S and C key, and both shader keys inside every R and M row, are in the shader map of the 1.8.0 build. No row is unreadable and none is there twice.
• Games run, with title ID and version: Mario Kart World (0400C3F00006E000), update 1.8.0 (v917504), about 15 scripted races on 2026-11-09. The host's control file pressed A through the menus and held it for the drive. I compared the [longframe] lines of the first race with a later one, sorted by the cause each line gives.
• Devices and OS: iPhone 19,4 (a Duo foldable, applegpu_g19p), iOS 27.3 beta.
• Not checked: the list as the bundled file. On the phone it was read as Documents/pso_user.tsv, which goes through the same reader. It hasn't been run on a Mac or on the base game. No regress.py run, since the change is one profile's data.
• Measurements before and after: the two races above. They aren't the same host build: the first is a build from PR WIP: Mario Kart World 1.8.0 on iOS - rendering, memory and presentation #1383, the later one is main 04811a6 with a few open PRs merged. Both wrote the same [longframe] fields.

Docs

• The finding is in its game note (dm/games/0400C3F00006E000/README.md, Shaders and Open). docs_symptoms.py wasn't run: the change adds no reference entry.
• A chain tool changed: dmsh_chain.py --header was run and dm/gfx/nvn/dmsh_chain.h is part of the change. Not applicable.
• No game files, keys or data extracted from a game in the change or the attachments. The rows are shader and pipeline keys (hashes), as in the lists already on main.