Ocarina of Time: GPU time per frame triples after a big scene change (leaving the Deku Tree) and stays up until restart (M2 Pro 16 GB) #2277

Activity

1. github-actions

   added

   macThe Mac front end and app (dm/mac, front_mac.m)The Mac front end and app (dm/mac, front_mac.m)

   bugSomething isn't workingSomething isn't working

   game: 0400486024DEC000A gameA game

   on Nov 11, 2026
2. qq3229311585-jpg commented on Nov 11, 2026

   

   qq3229311585-jpg

   on Nov 11, 2026

   More actions

   Another data point from a 16 GB fanless MacBook Air (M5, macOS 27.2), Ocarina of Time v131072, commit 01ec314 (chain b8856126d238, so the allocator-pool fix fd8188c9 is in), DM_FPS_TARGET=30, DM_GUEST_FILE=1. It looks like the same "GPU time per frame jumps and stays up until restart" state, with these differences from the report above: it starts about 40–80 s after the first 3D frame in the Kokiri plain (not after a scene change), the GPU time is about 1.5× (24 → 36 ms at the same spot), and it does not follow the draw count, but it goes away by itself in light scenes. It does not happen on every launch: one launch ran 70 minutes at a flat 33.3 ms (the only slow stretches matched macOS thermal pressure 0→1→2 and recovered when it fell), the next launch of the same app went slow after 40 s and stayed there.

   What powermetrics --samplers gpu_power,cpu_power,thermal shows in the slow launch (2 s samples, AC power, thermal pressure Nominal all the time):

   	good (first 35 s of 3D)	slow
   GPU HW active frequency	~1510 MHz	~890–1050 MHz
   GPU HW active residency	56–74 %	~100 %
   GPU Power	5.9–7.4 W	~1.7 W
   CPU Power	0.6–2 W	7–10 W (all four P cores at ~4.27 GHz)
   frame time p50 / GPU span p50	33.3 / 18–25 ms	52–65 / 32–41 ms

   So in the slow state the GPU is 100 % busy but is only given about 950 MHz and 1.7 W, while CPU+GPU together stay at about 10 W in both states. With DM_NVN_WAITS=1, the game's main thread blocks about 42–54 ms per frame in SyncWait on the GPU in the slow state (0.12 ms in the good state), and GPU waits so far stays 0, so it is the GPU itself that is slow, not the submission side.

   Things tried that did not fix it, in case they save someone time:

   • A small offscreen Metal compute load (12 % and 25 % duty, 40 s each) to "kick" the GPU clock: no change in frame time, GPU stayed ~900–1300 MHz.
   • DM_RT=0: still slow after ~1.5 min.
   • DM_QOS_MAP=1: the slow state came after about 12 minutes instead of 1–2, then the same pattern (GPU ~750–900 MHz at ~98 % busy, 1.4 W). More frames with a long tail, too.
   • Game Mode (off in Info.plist, no "Game mode enabled" in gamepolicyd), low power mode (off), memory/disk (resident 5.8–6.9 GB, 20 GB free) were ruled out.

   It reads to me like macOS power management on a fanless machine rather than something the game does, but I could not show that. I can attach the logs and the powermetrics files (no game files in them) if useful; my notes and small scripts are in https://github.com/qq3229311585-jpg/oot2-mac-notes.
3. qq3229311585-jpg commented on Nov 12, 2026

   

   qq3229311585-jpg

   on Nov 12, 2026

   More actions

   Correction and more data for my comment above (M5 Air 16 GB, 01ec314, DM_FPS_TARGET=30).

   1. My "good (first 35 s of 3D)" column was the title and file-select screens (2–30 draws a frame), in fullscreen on the 60 Hz link. In healthy gameplay the GPU also sits at 730–1140 MHz (P4–P8), 75–90 % active, 2–4 W, with 33.3 ms frames. So the low clock is not the fault. Please disregard the power-management reading in my first comment.
   2. The slow launches are slow from the first or second 300-frame window after loading into gameplay (frame p50 57–61 ms), not after a while.
   3. In the slow state a 5 s sample of dmhost has com.Metal4.SubmissionQueue active in 792 of 894 samples, 791 of them in iokit_user_client_trap. That looks like the bad state described in frame-rate.md ("The GPU idles with the next command buffer already committed").
   4. powermetrics shows the GPU "100 % active" in that state, but at the same clock it draws about 0.6× the power per active time of healthy gameplay (e.g. around 900 MHz: ~2.0 W against ~2.8 W). An offscreen compute load that pushed the clock to P12 for 10 s changed nothing (4.4 W at "100 % active", where healthy work at P12 is about 10 W).
   5. At a 30 fps cap kmax is 2 (hle_nvn.c, fstep_tick), so a run that falls into this state has no way out; it plays in slow motion until restart. The two slow-from-the-start launches whose logs I checked were in fullscreen (log: "fullscreen, fixed refresh"). One launch with DM_OPMODE=0 ran ~25 minutes with every 300-frame window at 33.3 ms; that is one run, so too little to conclude.

   I can attach the logs and the powermetrics files (no game files in them) if useful.