There have been some upstream API changes (like splitting screen_luminance into auto_adjust_reference_luminance and auto_adjust_maximum_luminance) which this PR has not been updated to cover. Do you plan on updating this PR once the upstream one has been merged? Asking because some things like high/low precision have different behaviour on wayland than it did on windows (on windows low precision is faster, on wayland high precision is faster) so mac might have even more different behaviour than either of them. Windows HDR on vulkan is broadly broken but it seems you've verified than on mac things work well?

The primary useful point of data would be which of high/low precision is faster on macos (and that they both work, on wayland they used to not work until changes were made to the godot vulkan driver).

@Calinou Thanks for testing this on Mac. There's a chance that some of this is from old bugs that have since been since been fixed (this hasn't been rebased in a while) but most likely there's some very important performance considerations around high/low precision on mac that would be worth bringing up with allenwp.

As for the hue shifts hopefully it's just a bug in the metal implemtation (the colorspaces chosen in metal say something about P3 which seems strange to me) but if there's also a bug in the vulkan implementation it's good to have caught it here.

Do you plan on updating this PR once the upstream one has been merged?

@ArchercatNEO absolutely! Just waiting for the upstream PR to stabilise and merge and I'll rework this PR. I'm very excited to add EDR support for Apple.

@Calinou identified a bug in how the MetalFX spatial shader is configured, that has been fixed in #109406

Running the test project. I've tested each run at least twice as many of the results are unexpected, namely HDR off being slower than HDR on (with high precision disabled).

I wonder if you would observe the same if you target a non-HDR display? Pure speculation, but is it possible that Apple's rendering / compositing pipeline on the MacBook Pro's built-in display is always HDR, so SDR content must be converted?

Generally, I've seen all Metal literature indicate the default pixel format it BGRA8 for views.

I think you can set the colorspace of the display to be SDR-only.

any way to get a precompiled build of this PR (a github actions CI link with artifact?) to do some testing on a mac Mini M4 with HDR monitor?

I have tested succesfully godot HDR Windows and Linux HDR support using artifacts.. but seems the current build has not Mac build artifact:
https://github.com/godotengine/godot/pull/106814/checks?check_run_id=42881854888
I'm ok?

any way to get a precompiled build of this PR (a github actions CI link with artifact?) to do some testing on a mac Mini M4 with HDR monitor?

I have tested succesfully godot HDR Windows and Linux HDR support using artifacts.. but seems the current build has not Mac build artifact: https://github.com/godotengine/godot/pull/106814/checks?check_run_id=42881854888 I'm ok?

I just looked into doing a rebase and pushing that, which would generate a new build artifact, but I'm having issues getting this PR working on my Mac when running a game project (before or after my rebase). We'll need to wait a bit longer to really test out Mac OS HDR output support.

Alright, it turns out my issues were just that I needed to run the game without the "Embed on next play" option selected in my Game workspace. Once I did this, it works fine.

I pushed the rebase and updates to fix colour space issues, but this PR now fails checks due to 'maximumPotentialExtendedDynamicRangeColorComponentValue' is only available on macOS 10.15 or newer [-Werror,-Wunguarded-availability-new]. It builds fine if you build it locally!

but this PR now fails checks due to 'maximumPotentialExtendedDynamicRangeColorComponentValue' is only available on macOS 10.15 or newer [-Werror,-Wunguarded-availability-new]

I'll have to add some availability checks to guard against running on older OSs

@stuartcarnie I've made changes to this PR to correct the way that Max/Reference luminance is handled. The rebase is going to be substantial, so please take note of the current state of the PR before the rebase; put simply, max luminance needs to be calculated as follows:

// Note: this absolute nits value is incorrect when reference luminance is below 100 nits.
// But that's OK because it will still be correct *relative* to reference luminance.
float max_luminance = screen.maximumPotentialExtendedDynamicRangeColorComponentValue * 100.0f;

And reference luminance can be calculated based on that and the current max value:

maximum_value = screen.maximumExtendedDynamicRangeColorComponentValue;

// Note: this absolute nits value is incorrect when reference luminance is below 100 nits.
// But that's OK because it will still be correct *relative* to max luminance.
float reference_luminance = max_luminance / maximum_value;

I've made changes to this PR to correct the way that Max/Reference luminance is handled. The rebase is going to be substantial, so please take note of the current state of the PR before the rebase;

@allenwp sounds good! Fortunately, GitHub makes it easy to compare between commits / rebases

@allenwp

• ✅ hardware reference luminance normalised; 100.0f for macOS, 100.0f for visionOS and 203.0f for iOS
• ✅ DisplayServer.xml updated
• ✅ Updated error to "Apple embedded devices"

@allenwp I re-synced and pushed the display_server_macos_base.mm file, so it should be good now.

I don't seem to be able to compile this PR on my MBP M4 Pro for some reason:

platform/macos/display_server_macos_base.mm:167:20: error: no visible @interface for 'NSScreen' declares the selector 'CGDirectDisplayID'
  167 |                 return [p_screen CGDirectDisplayID];

Any idea why?

@blueskythlikesclouds One time, I also had trouble compiling for Mac using scons, but the issue went away after restarting the OS. Not sure why this helps, though.

Edit: I should clarify that this OS restart was due to applying a security patch for macOS Sequoia. But the end result was still that Mac builds started working again after the restart.

No issue with basic scons platform=macos arch=arm64 in the terminal on MBP M2 Pro, macOS 26.3. Maybe specific to the newer M-series chips.

I don't seem to be able to compile this PR on my MBP M4 Pro for some reason

I do not get this error on M4 Pro, with Xcode 26.3 (17C529).

This property is documented as macOS 26+, but it's in @available(macOS 26.0, *) so it should not be an issue with older Xcode versions.

https://developer.apple.com/documentation/appkit/nsscreen/cgdirectdisplayid-7uvhw?language=objc

Hmm, odd. It doesn't compile from VSCode or the terminal but compiling within XCode works.

For reference, my macOS version is Sequoia 15.7.3

Hmm, odd. It doesn't compile from VSCode or the terminal but compiling within XCode works.

It might be a mismatch of Xcode and command line tools, which sometimes happens:

• Check the output of xcode-select -p command, if it's not /Applications/Xcode.app/Contents/Developer, run sudo xcode-select -s /Applications/Xcode.app/Contents/Developer.
• If it won't help, delete /Library/Developer/CommandLineTools and run xcode-select --install to reinstall command line tools.

@blueskythlikesclouds I was on a similar version of Sequoia when I ran into compilation issues. Then I upgraded to 15.7.4 and the compile succeeded.

See if that fixes the issue for you.

Check the output of xcode-select -p command, if it's not /Applications/Xcode.app/Contents/Developer, run sudo xcode-select -s /Applications/Xcode.app/Contents/Developer.

This works.

Thanks! Amazing work from everyone involved! 🎉

getting a build failure on this post-merge:

platform/macos/display_server_macos_base.mm:167:20: error: no visible @interface for 'NSScreen' declares the selector 'CGDirectDisplayID'
  167 |                 return [p_screen CGDirectDisplayID];

on m4 mac mini running 15.7.4 w/xcode 16.4, macos 15.5 sdk

See the discussion above, I had the same problem. #106814 (comment)

Make sure your Xcode is updated.

See the discussion above, I had the same problem. #106814 (comment)

i should've scrolled up, thanks!