[FeReuss]

What and why

Ocarina of Time (0400486024DEC000, v131072) is profiled with enc_thread on: the Mac replays the game's graphics queue and encodes it to Metal on a thread of its own, as iOS does for every game, instead of the submit thread stalling on each pass's encoding. With it the GPU of a MacBook Air M4 starves less at segment boundaries.

The one test it breaks is fixed in the same PR: t_feedback exercises the segment timestamp heap, which exists only without the encode thread (ts_on(): seg_ts() && !rec_on()), and rec_on() defaults to the profile's enc_thread. Under GAME=0400486024DEC000, three of its checks failed (segment mode has a timestamp heap, with work running: a boundary, no commit, and its timestamp slot). check_t_feedback now sets DM_NVN_ENC_THREAD=0, the mode it tests, as t_present_crop and t_perf_order set theirs.

Profile key only; no host code, no chain change. The game note's Frame rate section has the measurement.

Checked

• Tests: python3 -m unittest test_docs test_game_profile test_launcher_settings test_architecture (dm/tools/tests, 39 tests OK); make -C dm/gfx/tests GAME=0400486024DEC000 check_t_feedback: 203 checks, 0 failed (3 failed without the Makefile line, on this profile). The whole make -C dm/gfx/tests GAME=0400486024DEC000 run on the tree with every PR of the series, which has this profile: 150 suites, 72,812 checks, 0 failed; 525 read-back cases, 0 failed.
• Games run: Ocarina of Time 0400486024DEC000 v131072, the Hyrule Field view (still_shots route, the heaviest), 120 s runs, window, docked, 1920x1080, 60 fps cap, enc_thread off against on, the same host and shaders, one run each (not an in-process A/B: the switch is read once): frame p50 24.48 -> 23.46 ms (40.2 -> 41.6 fps), GPU p50 22.09 -> 21.39 ms. Measured on a tree of 2026-11-08 (main 7f502220 plus the series); this branch is rebased on 7a7acfee and built and unit-tested, not re-measured in the game.
• Devices and OS: MacBook Air M4 (10-core GPU, 16 GB, no fan), macOS 27.2.
• scripts/regress.py check: not run; a profile key of one game, and only Ocarina of Time is built on this Mac.

Front ends

None.

Docs

• The finding is in the game note (Frame rate) and docs/reference needs none: the key is documented (dm/games/README.md).
• A chain tool changed: no.
• No game files, keys or data extracted from a game in the change or the attachments

Series: what these PRs add up to

This PR is one of a set from one effort to make Ocarina of Time (0400486024DEC000 v131072) hold its frame rate on a MacBook Air M4. The set, and how its parts combine into the last measured result:

The result (the Hyrule Field view, the heaviest of the game: 1920x1080 docked, 60 fps cap, window, 120 s runs, M4 with 10 GPU cores, 16 GB, macOS 27.2):

Tree	fps	frame p50	GPU p50
main 7f502220 + #1304, fps_hold at its default	30.1	33.31 ms	27.56 ms
+ fps_hold off (#1927)	33.7	29.38 ms	27.28 ms
build 3: + #1833 with the M4 window fix, border-FC (#1929), the barrier set and cut_draws 128 below, and the PRs listed as "also in the tree"	40.2	24.48 ms	22.09 ms
+ enc_thread on (#1928)	41.6	23.46 ms	21.39 ms
+ native float add (#1930) = build 4	44.6	22.39 ms	20.45 ms

(The step from 33.7 to 40.2 changes the shader chain, so it has no in-process A/B; #1833 is most of it. Kokiri Forest, walking, is at 60 fps on build 4; the Hyrule view is the worst case.)

Each part switched in one process on build 4 (DM_AB, 210 s, 600-frame phases, frame p50 with the part active against without; the noise between phases is about 0.3 ms): border-FC (#1929) 22.61 vs 23.98 ms; the barrier set (FRAG_ORDER, PASS_OVERLAP and HEAP_RELAX alternating together) 22.41 vs 22.58 ms; CUT_IDLE 22.74 vs 22.85 ms; DISPATCH_CHAIN 22.32 vs 22.48 ms.

Which PRs make that tree:

Part	Where
fps_hold off	#1927
enc_thread on	#1928
border-FC	#1929
native float add	#1930
launcher's Render scale / GPU share (no frame-time effect)	#1931 (draft, on #1304)
M4 address window of shader_raw_direct (without it every raw store is dropped on an M4 and the foliage is not drawn: the 48-50 fps of a build without it are false)	the branch FeReuss:pr1833-m4-window, one commit on #1833's head (not yet offered on #1833 itself)
Base, other authors, open, in the measured tree	#1304 (tier 0), #1714 (gpu_ts_hz), #1833 (shader_raw_direct), #1720, #1377, #1840
Base, in the measured tree, already in main or withdrawn	#1844 (-fwrapv, now e4e5ff64), #1368 / #1708 (native mesh prewarm and mesh without task: main's own versions), #1707 (withdrawn)
Measured, not submitted (the net is within the noise): barrier set (FRAG_ORDER + PASS_OVERLAP + HEAP_RELAX), CUT_IDLE	branches pr/pass-overlap and pr/cut-idle in FeReuss/nxnative-oot
Not ported: dispatch chain (the same idea as #1901), cut_draws 128 (64 and 128 tie on this tree)

All of it was measured on main 7f502220 plus the above; these PRs are rebased on main 8d5d4f1b; the tool and docs tests that touch them were run again there (test_env_switches, test_docs, test_nsp_chain, and each PR's own), while the host build and the graphics suite are those of 7a7acfee, and none of it has been run in the game on the newer main (a shader rebuild of the new chain takes about an hour and 10 GB of disk). This PR is #1928.

🤖 Generated with Claude Code

[roandegraaf]

#2260 adds the same enc_thread on row for 0400486024DEC000, together with a texture view cache. On a GPU-bound outdoor scene (M4 Pro, headless), it measured 55.3–55.8 fps without the row and 56.5–56.9 fps with it. The two PRs conflict only in game.tsv, and whichever lands second drops the row.

One update: the DM_NVN_ENC_THREAD=0 on check_t_feedback doesn't seem needed any more. On #2260's branch (main at 01ec314), make -C dm/gfx/tests GAME=0400486024DEC000 check_t_feedback with enc_thread on in the profile and no Makefile change gives 278 checks, 0 failed.