[dpadr]

What and why

At the third stage of Splatoon Raiders' first boss fight (0400380020056000), the game dropped to 1-2 fps and stayed there until the stage ended. The GPU was busy 420-600 ms a frame, with up to 1,025 render passes a frame, against about 100 in the rest of the fight.

Cause. The stage measures its ink map with about 1,550 occlusion queries a frame. Before each query it makes 7 inline uniform updates, which comes to 11,010 queued writes in one submission (about 2,800 in the game's other fights). The host's list of a submission's queued writes (pend_add) held 8,192 entries. Past that limit:

1. The submission counted as a write anywhere (g_pend_over).
2. gw_commit carried that to later submissions while it ran (g_gw_all).
3. Every partly covered uniform shadow was refused, and each refusal ended the render pass.
4. Each query became a one-draw pass on the 6400x6400 map, the GPU fell behind, the overflowing submissions were still running at the next frame's draws, and the refusals went on.

Change.

• PEND_MAX 8,192 → 32,768. It stays under 65,536 because g_pend_upd is a 16-bit index + 1, which a static assert now checks.
• PEND_NODES 16,384 → 65,536, and 2,048 → 8,192 hash buckets.
• The tables take about 1.9 MB instead of 0.5 MB. An overflow still counts as a write anywhere.

Diagnostic. A pass dump now names the host function and line that ended each render pass: E <pass> pass ends in <function>:<line>, through a rp_end() macro over rp_end_at(__func__, __LINE__). It only writes while DM_NVN_PASSDUMP is on. Without it, the dump had no record at the point where these passes ended. With it, one run named draw_ → ubd_conflict.

The reference entry is A submission past 8,192 queued writes counted as writing everywhere. The game note's Rendering section and its "Found on this game" list link to it.

Checked

• Tests:

  • make -C dm/gfx/tests GAME=0400380020056000 check_t_ubp_running: a new case queues 10,850 updates in one submission. It fails 3 checks on main and passes all 11 here.
  • check_t_geometry (1,920 checks) and check_t_geometry_hazards (61), which set g_pend_over, pass.
  • test_tbdr_budget.py, test_docs.py and test_env_switches.py pass.

• Games run: Splatoon Raiders 0400380020056000, played docked on the Mac through the first boss fight's third stage. The before and after builds differ only by this change: both are main with PRAGMATA's opening load fits an 8 GB Mac's GPU working set: large-pool chunks retire, pools from 128 MB are chunked, and DM_NVN_TEX_MIP_SKIP #1319 merged in and its memory switches on (DM_NVN_TEX_MIP_SKIP=1, DM_NVN_GMEM_RES=0), with DM_NVN_GPU_TS=segment. The "after" run also had the pass-end diagnostic.

  	Before	After
  Frame time at the stage	400-1,100 ms	median 17.7-19.9 ms
  Render passes per frame, most	1,025	118
  Refused uniform shadows	173,452 (161,812 earlier submission running, 11,640 unreadable)	0
  Footprint	13-14 GB	12.6 GB at the end of the run

  The system's swap did not change across the drop: it looked like memory pressure but was not.

• Devices and OS: MacBook Air M2 (Mac14,2, 10-core GPU), 16 GB, macOS 27.0.

• regress.py impact origin/main..fix/pend-list-capacity: nvn_mtl.m reaches every NVN game. Of the profiles with a usage manifest: Breath of the Wild, Pokémon Scarlet and Tears of the Kingdom are affected, and Hades is broad (present path only).

• Not checked yet: scripts/regress.py check --games on those games, which are not on this Mac. The change only raises a limit, so behaviour below 8,192 writes a submission is unchanged. A game that passed the old limit now keeps its shadows instead of ending passes.

Docs

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

🤖 Generated with Claude Code

[seedds]

Landed as 6d5ed71, with you as co-author. Thanks for the clear diagnosis and the before/after runs.

One change from the PR: instead of raising the fixed limit to 32,768, the list no longer has a limit. Its entries and page nodes grow when a submission needs more room (pend_room) and keep that size, so a steady frame allocates nothing. g_pend_upd is 32-bit, so the 65,536 ceiling and the static assert are gone. This limit had already been raised once (256 → 8,192 for Monster Hunter Rise), and Raiders' query count changes with the scene, so a bigger fixed number would only move the cliff. A submission still counts as writing everywhere only when memory runs out or the 256-entry list of wide writes is full.

Kept as you wrote them: the test (now extended to 43,400 updates, past what a 32,768 limit holds), the reference entry, the game note and the rp_end_at pass-dump diagnostic. Its comment now says the line can be in an .inc file. Your measurements were on the fixed-limit version; the grown list gives the same result for the stage's 11,010 writes. If you replay the third stage on the M2, a confirmation on main would be welcome.

Checked here: t_ubp_running, t_geometry, t_geometry_hazards, t_sbw, and regress.py check on Octopath Traveler II (PASS: 59.8 fps both, shaders and MSL unchanged, no new red lines).