[sn0wst0rm]

Add HDR presentation on macOS and iOS, with launcher controls for Mario Kart World and Donkey Kong Bananza on both platforms. Negotiate display capability through VI, decode PQ and linear scRGB scanout into extended-linear Rec.2020, and apply content luminance metadata through Core Animation. Preserve SDR presentation and tone-map HDR screenshots to SDR. Bypass the perceptual SDR MetalFX scaler for HDR scanout.

Restore LSSupportsGameMode=true in Mac bundles. iOS already enables Game Mode and retains that configuration. The global opt-out followed an M4 Pro low-clock report; that issue and its per-game workaround remain documented. For MKW 1.8.0 on M5 Max, the queue timestamp and allocator-lifetime fixes in #1245 restored stable 60 fps with Game Mode enabled, without forcing GPU clocks or lowering resolution.

Validation: 178 GPU checks covering HDR luminance, gamut conversion, SDR output, crop handling and both Metal presentation paths; 114 packaging, profile, settings, documentation and shader-chain tests; all 263 iOS host sources compile. GPU tests pass with Metal validation enabled. Guest Bezier tone-curve overrides remain unsupported; Core Animation maps HDR to the display.

Front-ends: interface: expose DM_HDR from the shared settings list on macOS and iOS, and rebuild the host with its updated present shader. Mac bundles again opt into Game Mode.

[elieteyssedou]

A data point from an M4 Pro, on this game, for the Game Mode revert.

Setup: MacBook Pro M4 Pro (Mac16,8), 24 GB, macOS 27.0. Mario Kart World 1.8.0, fullscreen, 2026-11-03. Build: main 07ca3efc merged into #900 (02fcb806), so before cb59a672, and without #1245 or this PR.

One run, with Game Mode switched off in Game Overlay while playing:

	GPU p50	Frame p50
Game Mode on	36-39 ms	38-45 ms
Game Mode off, at once	8-10 ms	17-19 ms

Limits:

• I did not measure the GPU clock, so the link with the low clock in Mac: TotK drops to 30 fps because macOS pins the GPU at its lowest clock, and the frame step's probes can't bring it back #349 is inferred.
• It did not happen every time: an earlier run with Game Mode on, 17,400 frames, stayed at GPU p50 14.75 ms, up to 28.7 ms in some stretches.
• Honor NVN event dependencies across guest queues #1245 was not in that build, so this does not tell whether it fixes the problem on an M4 Pro.

For reference, with the key false: 24 minutes on main 975bb4c1 with #1176 merged locally, DM_PRESENT_LINK=0, held 60.0 fps on average at GPU p50 10.7 ms.

[sn0wst0rm]

Thanks for sharing these measurements. The slowdown was intermittent on my M5 Max too: some runs stayed at 60 fps, while others entered a persistent ~30 fps state near the rivers. Opening the pause menu restored 60 fps only in the menu; switching focus away from the app and back also restored performance in gameplay.

With the fixes now in #1245, I haven’t reproduced that state in my subsequent tests with Game Mode enabled.

Could you clarify how the slowdown behaved on your M4 Pro? Once triggered, did it persist, and did switching focus away and back recover performance without disabling Game Mode? If you can test with #1245 applied, a comparison with Game Mode on and off would help establish whether the issue remains on M4 Pro.

[elieteyssedou]

Thanks. This comes from gamepolicyd's log and my notes at the time; the frame log itself is gone.

• Did it persist? Game Mode was on from 17:13:58 to 17:17:44, about 3 min 45 s. The GPU p50 of 36-39 ms is from that stretch, and the game felt bad during it. I can't tell when in it the slowdown began, and I have no record of it recovering on its own.
• Focus: I did not try switching away and back. My run may not separate the two, though: I switched Game Mode off through Game Overlay, and gamepolicyd logged paused at 17:17:44, off at 17:17:45 and Game mode disabled at 17:17:59. Opening the overlay may count as the focus change you describe. GPU p50 was 8-10 ms after that, with Game Mode off.
• Honor NVN event dependencies across guest queues #1245: I have not run it yet.

[maxdavidson]

Thanks for this. #1176 covers the same ground (HDR output for Switch 2 games), and your findings here improved it:

• Format: your note that the SDK reads HDR as on only for format 1 checks out. Bananza's nn::vi::detail::DefaultDisplay::QueryHdrStatus (sdk+0x55bd60) sets on = (format == 1) and returns 0x272 for anything above 1. host/vi: HDR output for Switch 2 games on screens that can show EDR #1176 now cites it, crediting this PR.
• Screen capability: as with your dm_hdr_query, host/vi: HDR output for Switch 2 games on screens that can show EDR #1176 now answers HDR only while the window's screen can show EDR (potential headroom above 1). It reads that four times a second, so the answer follows the window. Mario Kart World and Donkey Kong Bananza both ask for the status every frame (neither uses the HDR status event). Moving the window to an SDR monitor makes the game switch to its SDR window, and moving it back switches it to HDR again. DM_HDR=2 forces HDR on any screen.
• System tone mapping: host/vi: HDR output for Switch 2 games on screens that can show EDR #1176 first rolled highlights off in the present. It now uses CAEDRMetadata HDR10 with the game's declared extended range instead (Mario Kart World raises it from 0–1000 to 0–1801 nits at the title). Side by side they looked the same. Present-to-screen time was the same in SDR and HDR, about 49.6 ms p50 windowed, measured from the drawables' presented time.
• A GPU test: t_present_hdr, modelled on your t_present_hdr.m.

Where #1176 differs:

• 1.0 in the layer is the 203-nit paper white (the metadata's opticalOutputScale is 203), for PQ and SDR frames alike. So the SDR frames before the game switches have the same white as its HDR UI. Here, SDR frames are at 100 nits and the HDR white at 203.
• The setting is shown for every Switch 2 game, detected from the SDK's Ounce spec rather than a per-game hdr key, and it's off by default.
• MetalFX upscaling stays on for HDR frames. It runs on the PQ values, before the decode.
• RGBA16F (scRGB) windows aren't decoded, since no game we ran makes one.
• The Game Mode change isn't included, to keep that PR to HDR.

Happy to merge efforts, either by folding anything from here into #1176 or the other way round.

— Claude Opus 5.5, via Claude Code