[AdyaGMD]

What and why

Ocarina of Time (0400486024DEC000) upscales with agl's chained upscaler, agl_ndsr_vr.pck / agl_ndsr_vr_light.pck. That's four compute dispatches a frame where Donkey Kong Bananza's agl_ndsr.pck uses one:

1. The first reads the frame's colour (1440x810 R11G11B10F in handheld mode) and writes a quarter-size image and two storage buffers.
2. The second and third pack that into two R32Uint images.
3. The network reads the last of them and writes the 1920x1080 output.

DM_UPSCALER=metalfx (the launcher's Game's upscaler) only named agl_ndsr.pck's shaders, so it did nothing in this game. On an M1 the chain took about 3.4–4.4 ms of every frame.

This change:

• game.py finds the chain's shaders in the shader map (DM_GAME_UPSCALER_CHAIN_KEYS).
• up_chain_dispatch draws the network with MetalFX's spatial scaler from the colour the first dispatch read, using the network's own rectangles (up_mfx_encode_from), and leaves out the three stages before it.
• The network is the dispatch with one texture and one image where the image is larger than the texture. The first stage has the same shape but writes a smaller image.
• A network variant whose code has no colour curve is linear, so it goes through MetalFX in HDR mode. A variant with an sRGB curve runs the chain.
• The stages are left out only while the previous frame's network was drawn by MetalFX and this frame's colour is known. If MetalFX refuses, no frame is lost: the chain runs whole from the next frame on, and the left-out stages of that frame are logged in red.

The option is the existing launcher setting Game's upscaler (DM_UPSCALER), so players choose it. It changes the look of the upscaled picture: MetalFX's spatial scaler instead of the game's network.

The game note (dm/games/0400486024DEC000/README.md) describes the chain.

Checked

• Ocarina of Time 0400486024DEC000 v131072, Mac app, M1 (8-core GPU), macOS 26, handheld mode, 30 fps target. Played through the opening and some gameplay.
  • Log: upscaler chain fa3033d05c0a41d6_b: the network, no colour curve: MetalFX in HDR mode, then drawn by MetalFX from the chain's colour, 1440x810 … → 1920x1080. The three earlier stages are left out. No red lines.
  • The second submission's compute fell from about 4.4 ms to 0.5 ms a frame.
  • Gameplay went from 24–25 fps to 27–30 fps, measured together with the scene-pass change (separate PR).
• Tests: dm/tools/tests/test_game_profile.py covers the new chain keys (test_chain_from_shader_map). It and the GPU tests were not run locally; CI runs the tool tests.
• Not checked: other games using agl_ndsr_vr (none known besides this one), and iPhone.
• No shader-chain change.

Docs

• The finding is in the game note (dm/games/0400486024DEC000/README.md)
• No game files, keys or data extracted from a game in the change or the attachments

This touches dm/games/game.py and test_game_profile.py next to the movie-enhancement PR. Whichever lands second needs a small rebase.

🤖 Generated with Claude Code

[bquilty25]

60 FPS Validation on Apple Silicon:

Tested this change over an extended 24,000+ frame (~7 minute) gameplay session in The Legend of Zelda: Ocarina of Time (0400486024DEC000 v131072) with a 60 FPS target (DM_FPS_TARGET=60 and DM_UPSCALER=metalfx):

• Spatial Scaler GPU Timing: Present command buffer GPU time consistently measures p50 = 0.318–0.512 ms, p95 = 0.623–0.912 ms (down from ~4.4 ms compute with the full chain).
• Frame Pacing: Sustained 59.8–60.0 FPS with 0 dropped frames across Kokiri Forest and area transitions.
• Stability: The 3 intermediate dispatches are cleanly elided without visual degradation or missing passes.

Note on CI Failure (lint-c/clang-tidy):
Clang-tidy is failing on line 15036 of nvn_mtl.m:

if (!cs->up_color && DM_GAME_UPSCALER_CHAIN_N && up_mfx_on() && up_chain_named(cs))

Because DM_GAME_UPSCALER_CHAIN_N expands to a constant macro integer, clang flags it as [-Wconstant-logical-operand]. Changing it to DM_GAME_UPSCALER_CHAIN_N > 0 resolves the warning and should turn the CI check green.

[fheitzer]

Measured on an M1 Max (32-core GPU, applegpu_g13s, 32 GB, macOS 27.0.1), Ocarina of Time v131072, main f02d047 plus #1970 and #1901, handheld (where the game runs agl_ndsr_vr_light), 60 fps target, scripts/bench.py.

On main without this PR, DM_UPSCALER=metalfx does nothing on this game (46.1–46.6 fps either way, GPU 19.3 ms): the upscaler keys come only from agl_ndsr.pck.

With it, the game's upscaler goes through MetalFX (3 runs each, alternating):

	fps	frame p50 / p95	GPU span p50	frames shown 2 vsyncs
combined, DM_UPSCALER=game	49.7 (standing part of kokiri-deck)	20.2 / 22.8 ms	23.6 ms	20–21%
combined, DM_UPSCALER=metalfx	53.3 (standing part)	18.5 / 21.2 ms	20.4 ms	12–13%

On a 2-minute standing route (same view at any frame rate): main 47.15 fps → combined with metalfx 52.9 fps, frame p99 23.2 → 21.3 ms. On the full kokiri-deck window the metalfx runs reach 53.1 fps, but Link's path diverges at the higher frame rate (he ends on a ledge instead of in the pond), so I quote the standing numbers. The per-encoder profile before it showed the network as a 2.46 ms compute block per frame on this GPU. The picture looks right in the screenshots (colours, no washed-out image). It conflicts with main in two places (main's ndve_engine_dispatch declaration next to up_chain_dispatch, and main's threadgroup-spill setup in dispatch); keeping both, with the chain's early return before the spill setup as your merge commit says, builds and runs.