[stan69b]

Fixes #2535.

What changes

VIS_RING goes from 8 (ALLOC_MAX) to 128 in nvn_mtl.m. vis_take already grows the ring lazily and reuses a buffer once its submission's fence passes, so the ring only grows to the number of counting submissions actually in flight. That's at most 8 MiB, all kept resident.

Why it matters: since fd8188c9, a frame's submissions share a command allocator, so more counting submissions are in flight than allocators. With the GPU behind, the ring of 8 was often all in flight. Each counting submission then made a 64 KiB buffer of its own and added it to the residency set, then removed it after the submission. That's two residency commits through the kernel's GPU driver per counting submission.

Measured

iPhone 17 (A19, 8 GB, iOS 27.2.1), Ocarina of Time at the launcher's 30 fps cap with dynamic resolution, from a save. The build was the owner's local build (main 547c5db6 with #1971, #2270 and #2241), with and without this change:

	Before	After
Kakariko Village, fps	8–12	25–26
Kakariko, frame p50	62–118 ms	37 ms
Kakariko, GPU p50	25–45 ms	20 ms
Kakariko, residency commits per 300 frames	1,700–5,000	51–89
Hyrule Field, fps	10–12	29.5
Hyrule Field, frame p50	69–78 ms	33 ms

The cause was found from a sysdiagnose spindump. The game's main thread was in nvnSyncWait → mtl_wait_at, and the Metal 4 submission threads were in IOGPUFamily. Details are in the issue.

Checked

• t_wait_event: a new case runs 24 counting submissions in flight, none complete. Each takes a distinct ring buffer, and once they complete the next one reuses one without growing the ring. The case fails on main (2 of its 3 checks).
• t_render_enable_queue, t_render_counter_overlap, t_counter_clock and test_docs pass.
• The Mac host builds.
• Docs: a reference entry in docs/reference/frame-rate.md after the shared-allocator entry, the symptom index, and a line under Ocarina of Time's "Found on this game".

Regression check

Not run yet. On this Mac only Ocarina of Time reaches counting submissions often enough to matter, and a Mac never ran the ring dry (the reference entry for fd8188c9 says the same for an M4 Pro). A scripts/regress.py check on Ocarina of Time will be added here when it has run.

[stan69b]

Regression check

scripts/regress.py check --games 0400486024DEC000 (full mode), baseline 8d44aaf8 (this PR's merge base with main), candidate e2b01ddd (this PR's head). Apple M4, macOS 27.2, Xcode 27.2. Run from a tree that has Ocarina of Time's route (smoke.tsv, which main does not have yet), so the boot run took place.

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
Ocarina of Time 0400486024DEC000	REGRESSION (screenshots only, see below)	42848/42848 → 42848/42848	0	0	0	0 / 0	ok	59.5 → 59.5	17.82 → 17.93	2879 → 2860	3.28 → 3.68	0

• Prebuild: 33,365 pipelines built and 0 failed on both sides (985.5 s → 981.8 s).
• First frame: 12.1 s → 12.6 s. Highest frame number: 23,248 → 23,198. The route was reached on both.
• The only finding is the screenshots at 350 s and 385 s (dHash 18 and 24 bits). The baseline has a single run, so its noise is 0.
  • Both runs show the title screen rendered correctly.
  • The title's background cycles through scenes. The candidate started 0.5 s later, so at the same wall-clock second it shows another scene: baseline forest and ranch, candidate desert and lake.
  • This is a timing artifact of the route's fixed screenshot times, not a picture regression.
• No change in shaders, frame pacing, memory or red lines.

[seedds]

Landed in b515089, with you as co-author. Thanks for the diagnosis, the spindump and the iPhone numbers.

One change on top: the ring is now sized to the most submissions that can be in flight, not 128. mtl_sub_begin already caps that at ALLOC_MAX * ALLOC_SHARE = 512, the same limit the post ring relies on (PR #2469). Both now share SUB_FLIGHT_MAX. With that size the ring can't run dry; 128 could still run dry in a game with more counting submissions in flight. It still grows on demand, so memory stays the same in practice (32 MiB at most). vis_in_ring also became an O(1) check of this submission's ring buffer instead of a scan over the ring.

Your test, the symptom line and the game-note line are unchanged. The reference entry's Fix line was updated to match. t_wait_event, t_render_enable_queue, t_render_counter_overlap, t_counter_clock, t_perf_order and test_docs pass.

A retest on the iPhone 17 with main would confirm the numbers with the larger ring.