[givethesourceplox]

What and why

Ocarina of Time's title movie shows rectangular color blocks. Earlier GPU readbacks found a clean 1920×1080 RGBA frame after AV1 decoding and color conversion; corruption first appeared in the following NDVE intermediate and carried through to the 2560×1440 output.

With DM_NVN_NDVE_MOVIE_DIRECT=1, scale that clean frame into the movie's normal output with a bilinear Metal draw. Match the conversion shader, same-submission lifetime, RGBA8 image formats and observed dimensions. The option is off by default and deliberately substitutes standard spatial scaling for NDVE reconstruction; the original translation error remains open.

This update also recognizes the contiguous 13-dispatch reconstruction sequence. Encode the native draw successfully before skipping its 12 intermediate dispatches and final reconstruction dispatch, while still replaying all bindings. Unknown keys, indirect dispatches, side-effect commands, invalid image bindings or mismatched outputs retain the original path. Compute-hoisted conversion does not initiate the sequence skip. Reset pending state at each submission boundary. The destination requires render-target usage, without unnecessarily demanding shader-write usage on the first frame.

Rendering reference. The small SDK-26 setter declaration now included is the same prerequisite as #1404: runtime calls retain their existing OS-27 availability guard.

Checked

Apple M1 Pro, macOS 26.5.2, Xcode 26.5:

• Updated t_ndve_movie passes with Metal validation. It checks the 1080p-to-1440p draw, a destination without shader-write usage, output samples at both corners and the center, full-sequence recognition, wrong-key/indirect/missing-image/side-effect rejection, skipped dispatches, and preserved final program/image bindings.
• Documentation tests: 11 pass. Chain tests: 17 pass. LLVM static analysis of production code and fixture: no new findings. git diff --check passes.
• Prior local Ocarina integration run: title ID 0400486024DEC000, v1.1.1, title menu reached; captured movie frames had no rectangular corruption with the direct path enabled. This exact standalone PR branch has fixture validation; the game still needs [WIP] The Legend of Zelda: Ocarina of Time (Switch 2, 0400486024DEC000, v0, SDK 22.2.8) runs on the Mac through the title movie into Kokiri Forest #1299's bring-up work and other open fixes.
• No new isolated gameplay/FPS or power measurement, iPhone run or five-game regression report is claimed. This option changes movie reconstruction only and does not solve slow 3D gameplay.
• Shader chain and shader-library inputs unchanged; no game shader rebuild.

Docs

• Rendering finding updated; symptom index regenerated.
• Shader chain unchanged.
• No game files, keys or extracted data included.

[crypt0dj]

Second M1 Max report, and a warning about rebasing this onto current main

Rebased onto main bd979ced (chain 3ee52af3ca18) and measured on Ocarina of Time 0400486024DEC000 v131072, MacBook Pro M1 Max 32 GB, macOS 27.0.1 (26A434), applegpu_g13s. Windowed, DM_UPSCALER=game, DM_PRESENT_UPSCALE=off, same save point, only the switch differing.

The movie result reproduces, and then some. Movie frames, matched by their 3-pass signature:

	n	GPU median	p95	frame	fps
main	571	24.86 ms	25.02	25.00 ms	40.0
DM_NVN_NDVE_MOVIE_DIRECT=1	2687	1.13 ms	1.26	16.66 ms	60.0

−95.5 % of GPU, and the log confirms the path (scaling the decoded RGBA frame directly from 1920x1080 to 2560x1440, skipped 12 reconstruction dispatches). Zero [RED] lines over the run.

---

The warning. The patch calls mtl_pool_gpu_written(desc->pool) in ndve_scale, which current main does not have: pool_t.gpu_written and g_pool_gpuw_new are gone, replaced by address-range spans (mtl_tex_gpu_written). The literal translation compiles and looks right. It made gameplay unplayable.

Same binary, same save, DM_NVN_NDVE_MOVIE_DIRECT=1 throughout, against a diagnostic build that left only that call out. Frames of 2000+ draws:

	with mtl_tex_gpu_written(desc)	without
frame time	215.2 ms	33.7 ms
submit thread (@sub_wall_ms)	205.2 ms	9.2 ms
instructions retired a frame (@sub_instr)	1.73e9	6.6e7
GPU	45.9 ms	35.7 ms

The GPU was never the cost. No pipeline was built, no texture uploaded (new pipelines 0 + shader libraries 0, texture uploads 0 first + 0 re-uploads), and page faults, mprotect calls and pages were identical in both (4 / 12 / 138 a frame) — so it is not the write protection gws_stamp installs, which is what I first assumed and had to drop.

The mechanism is the span's lifetime. mtl_tex_gpu_written records the movie's 2560×1440 output, about 14 MB, and the span stays for the rest of the run. gws_owned, which tex_cpu_content calls for every uncompressed 2D texture (nvn_mtl.m:3734, :3753), walks the overlapping spans and scans that range's dirty pages under g_gws_mu on each one. Hundreds of textures a frame, each scanning 14 MB of page state. Outdoor areas are worst because they reach more textures a frame — which is exactly how it shows up in play: interiors fine, exteriors a slideshow.

Dropping the call, rather than translating it, looks like the right port. mtl_tex_gpu_written's only other caller on main is the shader-image case at nvn_mtl.m:8977; no render target is recorded through it. This output is a render target — ndve_scale checks out.usage & MTLTextureUsageRenderTarget before it does anything — so main's render-target path already covers what its storage is worth. With the call gone, the movie keeps 16.7 ms / 60 fps and gameplay returns to 33.7 ms against 29.7 on plain main, over 12,217 frames.

Not checked: picture quality of the bilinear scale against the network, by eye or by measurement; whether the same applies to any other game; and I have not run regress.py check --games.

(The comparison that produced this was between three runs of one binary; happy to attach the per-frame TSVs if useful.)

[crypt0dj]

Follow-up on the one thing my earlier report left open: the picture.

Watched the opening on the M1 Max with DM_NVN_NDVE_MOVIE_DIRECT=1 and saw no quality loss worth reporting. By eye, at 2560×1440, the bilinear scale is not distinguishable from the network's output in normal viewing. This is an eye check by the person running it, not a measurement against a reference frame, so take it for what it is.

One more data point: this ran with DM_UPSCALER=metalfx and DM_PRESENT_UPSCALE=metalfx, not the game scaler my measurements used, and the path still engages (NDVE movie: scaling the decoded RGBA frame directly…, skipped 12 reconstruction dispatches). So the movie path is independent of the upscaler choice — MetalFX replaces the NDSR network, not NDVE — and nobody has to choose between MetalFX and 60 fps movies.

[matijagrcic]

Tested in my NX2Apple 1.2.3-based with DM_NVN_NDVE_MOVIE_DIRECT=1. The movie/title sequence runs around 60 fps, and the log confirms direct scaling of the decoded frame with reconstruction dispatches skipped. This is included alongside #1427, #1707 and #1708 in my working build.

[seedds]

Thank you for this, and thanks to everyone who measured it on M1 Max and M1 Pro: those reports showed how much the network cost on smaller GPUs.

I'm closing this without landing it. c66a36a takes a different route to the same goal: nn::ndve's movie network now runs as the host's own Metal kernels, on by default (from #1894, reworked). It computes the same picture as the game's network rather than a bilinear scale of the decoded frame. In check mode over 1,500 frames, it matched the game's network in all but 10 texels, each off by 1/1023. On an M4 Pro the title movie's GPU time went from 12.78 to 6.77 ms a frame; on an M1 Pro the network alone went from 36.3 to 10.8 ms (#1894's standalone measurement). That should bring the title and the movies to 60 fps on M1-class Macs, but nobody has measured that in the game yet.

Skipping the network would still be cheaper (about 1 ms), but the picture is no longer the game's, so it's a workaround we'd only keep if the engine fell short. If it still doesn't reach 60 fps on your Mac, please post the frame's GPU time (DM_NVN_GPUPROF=every:600) on #1375 and we'll look again.