I gave this a quick test locally (on Windows 11 23H2 + NVIDIA 560.80 + LG C2 42"), it works as expected. This is encouraging to see, I've been wanting this for a while 🙂

I'll need to look into building more extensive scenes and getting tonemapped screenshots/videos out of this. 2D HDR also needs to be tested thoroughly.

Remember that JPEG XL or AVIF for images and AV1 for videos are a must for HDR, as other formats can only store SDR data. You may need to embed those in ZIP archives and ask users to preview them in a local media player, as GitHub doesn't allow uploading those formats and browsers often struggle displaying HDR correctly.

I noticed some issues for now:

• Having RTX HDR enabled will mess with the HDR that is enabled in the editor. It will continuously enable and disable itself whenever you make any input in the editor (and disable itself after being idle for a second). This is also an issue on master with HDR disabled.
  • See [4.3 Beta 3] Strange editor brightness and colors caused by RTX Dynamic Vibrance affecting the editor #94231. We should see if we can forcibly disable RTX HDR and RTX Dynamic Vibrance for the editor using a NVIDIA profile. I haven't seen options for those in NVIDIA Profile Inspector so far.
• HDR Max Luminance affects both 2D (UI) and 3D rendering. Is that intended?
• The HDR editor setting is not applied instantly when you change it, even though the demo project shows a working example of it being toggled at runtime. You can update the viewport's status based on editor settings here:

  godot/editor/editor_node.cpp

  Line 356 in ff8a278

  void EditorNode::_update_from_settings() {

• There doesn't appear to be a paperwhite setting you can use to adjust UI brightness. This is typically offered in games to prevent the UI from being too bright. Using a paperwhite value around 200 nits is common, since a lot of OLED displays cap out at that brightness level in SDR. Either way, this should be exposed in the project settings and the documentation should recommend exposing this setting to player (just like HDR peak luminance).
  • There should also be a way for unshaded materials to base themselves on paperwhite, so that Sprite3D and Label3D used for UI purposes are not overly bright in HDR. I suppose this would be a BaseMaterial3D property or a shader render mode.
    • In the interest of compatibility, we may not be able to enable this by default in Sprite3D due to VFX usage (where HDR display can be intended), but for Label3D, we may be able to safely default to this.

See the settings exposed by the Control HDR mod for an example of a best-in-class HDR implementation (related video):

Interesting, that UI seems to use the term "paperwhite" in a different way, and has a dedicated setting for the brightness of UI and HUD elements.

I gave this a quick test locally (on Windows 11 23H2 + NVIDIA 560.80 + LG C2 42"), it works as expected. This is encouraging to see, I've been wanting this for a while 🙂

Thanks for taking a look!

I noticed some issues for now:

* Having RTX HDR enabled will mess with the HDR that is enabled in the editor. It will continuously enable and disable itself whenever you make any input in the editor (and disable itself after being idle for a second). This is also an issue on `master` with HDR disabled.

* See [[4.3 Beta 3] Strange editor brightness and colors caused by RTX Dynamic Vibrance affecting the editor #94231](https://github.com/godotengine/godot/issues/94231). We should see if we can forcibly disable RTX HDR and RTX Dynamic Vibrance for the editor using a NVIDIA profile. I haven't seen options for those in NVIDIA Profile Inspector so far.

Odd that NVidia's RTX HDR doesn't detect the HDR color space and avoid messing with the final swap chain buffer. Auto-HDR in Windows 11 appears to avoid messing with Godot when HDR is enabled. Updating the NVidia Profile may be outside the scope of this PR and be best done with a more focused PR.

* HDR Max Luminance affects both 2D (UI) and 3D rendering. Is that intended?

For the initial draft, yes, everything is mapped using the same tonemapper. However, we should map UI elements to a different brightness to avoid them being too bright. For now, that can be worked around with dimming the brightness of any UI elements via the theme, but I would like to fix that in this PR.

* The HDR editor setting is not applied instantly when you change it, even though the demo project shows a working example of it being toggled at runtime. You can update the viewport's status based on editor settings here: https://github.com/godotengine/godot/blob/ff8a2780ee777c2456ce42368e1065774c7c4c3f/editor/editor_node.cpp#L356

I haven't looked into configuring the editor to use HDR yet. Will do after I figure out how to properly tone map UI elements, if you enable HDR on the editor now, the UI is a little unpleasant.

* There doesn't appear to be a paperwhite setting you can use to adjust UI brightness. This is typically offered in games to prevent the UI from being too bright. Using a paperwhite value around 200 nits is common, since a lot of OLED displays cap out at that brightness level in SDR. Either way, this should be exposed in the project settings and the documentation should recommend exposing this setting to player (just like HDR peak luminance).

Agreed, UI elements and other 2D elements should probably be mapped to a different brightness curve. I'll probably have to figure out where in the engine 3D and 2D elements are composited together and perform the tone mapping there.

  * There should also be a way for unshaded materials to base themselves on paperwhite, so that Sprite3D and Label3D used for UI purposes are not overly bright in HDR. I suppose this would be a BaseMaterial3D property or a shader render mode.

    * In the interest of compatibility, we may not be able to enable this by default in Sprite3D due to VFX usage (where HDR display can be intended), but for Label3D, we may be able to safely default to this.

That might be outside of the scope of this PR. I'm not sure how I would indicate that certain 3D elements need to be mapped using a different brightness curve once they are all combined into the same buffer. It would be similar to trying to avoid sRGB mapping certain rendered elements.

For now, this can be worked around by decreasing the brightness of the color of these elements.

See the settings exposed by the Control HDR mod for an example of a best-in-class HDR implementation (related video):
control_hdr_mod_settings.mp4

Interesting, that UI seems to use the term "paperwhite" in a different way, and has a dedicated setting for the brightness of UI and HUD elements.

Baldur's Gate 3 and Cyberpunk 2077 also have really nice HDR settings menus. I've been basing some of this work off their approach, though modifying contrast and brightness I'm leaving up to Environment since those effects are already there.

Thanks again for your comments! I'll add some TODO items to the description for tracking.

Can you use any Godot project to test this PR? Bistro-Demo-Tweaked and Crater-Province-Level both use physical light units, and use as close to reference values for luminosity on light sources. (i.e. the sun at noon is 100000 lux, the moon at midnight is 0.3 lux)

I'd love to help test this PR but unfortunately I don't have HDR hardware ☹️

I recently got a monitor that supports fake HDR DisplayHDR 400 so I thought I could give this a try, but on Intel UHD 620 it prints "WARNING: HDR output requested but no HDR compatible format was found, falling back to SDR." and doesn't display in HDR. I was kind of expected this since it is using Vulkan, but I'm a bit surprised it works for you, even on windowed mode no less. I guess there is some special handling in the NVIDIA driver?

Anyway, adding HDR output to D3D12 should be trivial and I might give it a try. (No promises!)

Shall we also consider implementing HDR display for the compatibility renderer? I am not sure if native OpenGL can do HDR, but it is very possible to implement on Windows with the help of ANGLE and some manual setting up.

This needs a rebase on master, but I have a https://www.dell.com/en-ca/shop/alienware-34-curved-qd-oled-gaming-monitor-aw3423dw/apd/210-bcye/monitors-monitor-accessories HDR display.

I can help test.

Can you use any Godot project to test this PR? Bistro-Demo-Tweaked and Crater-Province-Level both use physical light units, and use as close to reference values for luminosity on light sources. (i.e. the sun at noon is 100000 lux, the moon at midnight is 0.3 lux)

I'd love to help test this PR but unfortunately I don't have HDR hardware ☹️

You should be able to test with any scene, though keep in mind that the realistic light units will not map directly to the brightness of the display. Consumer desktop displays typically don't go much above 1000 nits on the high end, which is far too dim to simulate sunlight. Values from the scene will be mapped to a range fitting within the max luminosity set for the window.

Here are the changes to get Rec. 2020 HDR output on D3D12: master...alvinhochun:godot:hdr-output-d3d12

The over-exposure in your screenshot is expected, but the colours are oversaturated because it is missing a colour space conversion. The colours need to be converted from BT.709 primaries to BT.2020 primaries. This is how it should look with the correct colours:

The conversion may be done with something like this:

diff --git a/servers/rendering/renderer_rd/shaders/color_space_inc.glsl b/servers/rendering/renderer_rd/shaders/color_space_inc.glsl
index 3583ee8365..76305a8a3c 100644
--- a/servers/rendering/renderer_rd/shaders/color_space_inc.glsl
+++ b/servers/rendering/renderer_rd/shaders/color_space_inc.glsl
@@ -19,6 +19,15 @@ vec3 linear_to_st2084(vec3 color, float max_luminance) {
        // max_luminance is the display's peak luminance in nits
        // we map it here to the native 10000 nits range of ST2084
        float adjustment = max_luminance * (1.0f / 10000.0f);
+       color = color * adjustment;
+
+       // Color transformation matrix values taken from DirectXTK, may need verification.
+    const mat3 from709to2020 = mat3(
+          0.6274040f, 0.0690970f, 0.0163916f,
+          0.3292820f, 0.9195400f, 0.0880132f,
+          0.0433136f, 0.0113612f, 0.8955950f
+       );
+       color = from709to2020 * color;

        // Apply ST2084 curve
        const float c1 = 0.8359375;
@@ -26,7 +35,7 @@ vec3 linear_to_st2084(vec3 color, float max_luminance) {
        const float c3 = 18.6875;
        const float m1 = 0.1593017578125;
        const float m2 = 78.84375;
-       vec3 cp = pow(abs(color.rgb * adjustment), vec3(m1));
+       vec3 cp = pow(abs(color.rgb), vec3(m1));

        return pow((c1 + c2 * cp) / (1 + c3 * cp), vec3(m2));
 }

Rebased and squashed down into a single commit.

I have force-pushed a docs change that swaps the word "display" to "screen" to better match existing Godot APIs, which primarily use the term "screen" to refer to the physical hardware.

I noticed when reviewing these docs that I failed to update the glow blending docs in RenderingServer in one of my previous PRs. Since this PR touches those glow blending docs, I have copied over the new text into RenderingServer as well to correct the existing mistake.

Additionally, I've updated the public HDR output API to not expose Window.is_hdr_output_supported. To me, this appears to be an oversight from the API review meeting we had. There are no notes in our spreadsheet on this property, and we un-exposed a number of the other similar properties from Window (leaving only the DisplayServer ones). I believe the spirit of our changes was to remove this one from Window as well, even though we failed to document this.

@DarkKilauea @blueskythlikesclouds It appears, to me, that the recent optimizations to retrieving HDR screen info (luminance values and SDRWhiteLevel) have broken the detection of changes from SDR to HDR:

I cannot reproduce this, when I run my testing project (https://github.com/DarkKilauea/godot-hdr-output), both starting with HDR disabled and enabled, the Win+Alt+B sequence works every time. Also works fine when changing display settings in Windows to disable and enable HDR.

System specs:
Godot v4.7.dev (89c30f9) - Windows 11 (build 26200) - Multi-window, 2 monitors - Direct3D 12 (Forward+) - dedicated NVIDIA GeForce RTX 3090 (NVIDIA; 32.0.15.9174) - AMD Ryzen 7 3800XT 8-Core Processor (16 threads) - 31.91 GiB memory

Also works fine on my end. Both the shortcut and the Windows setting get detected by Godot, as well as the reference luminance setting.

Godot v4.7.dev (a54d6d8) - Windows 11 (build 26220) - Multi-window, 2 monitors - Direct3D 12 (Forward+) - dedicated NVIDIA GeForce RTX 3070 Ti Laptop GPU (NVIDIA; 32.0.15.9144) - AMD Ryzen 7 6800H with Radeon Graphics (16 threads) - 31.26 GiB memory

I updated my bug report comment with my system info.

After some more trying, the bug doesn't happen 100% of the time for me. But thankfully, it still happens most of the time so I was able to catch when debugging. It seems that sometimes when the WM_DISPLAYCHANGE event fires, the DXGI_OUTPUT_DESC1 is still reporting DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709. I suspect that the pre-optimized code worked because it would poll DXGI_OUTPUT_DESC1 every frame and pick up the delayed change to DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020, thus correctly updating the Window to show that HDR output is now supported.

From looking at this new code it seems that there is probably another bug that exists: As I shared in a previous comment, changes to maximum luminance do not trigger the WM_DISPLAYCHANGE event, which means that maximum luminance must be polled, just the same as SDRWhiteLevel. This is because any time the screen brightness on a laptop with a built-in HDR screen is changed, the maximum luminance values will change, so this will happen often on some screens.

@allenwp I believe I've resolved the issues you discovered.
@blueskythlikesclouds FYI so you can look at the performance numbers.

I've reverted back to loading the entire HDR state on each frame. This does undo some of the performance improvements gained, but should guarantee HDR output matches the screen in all situations. insert gripe about Windows missing events for HDR display changes

I tried a number of approaches to reduce the performance overhead:

1. Calling DXGI and gathering reference luminance in another thread. This didn't end up working due to the COM model DXGI uses, which expects to be called from the same thread once initialized.
2. Batching all calls needed to gather information for all displays into a smaller set, reducing the number of round trips through the kernel as much as possible. This actually ended up slower than what I eventually landed on due to allocation overhead and processing display paths that were not actually needed. This approach may be faster if there are many HDR windows on many displays, but it is slower for the common case of one window on one display. You can see that approach here: https://github.com/DarkKilauea/godot/tree/rendering/hdr-output-cache
3. Keeping the original approach but reducing the number of trips through the kernel as much as possible. This is what I merged into this PR.

My latest performance numbers are:

@blueskythlikesclouds FYI so you can look at the performance numbers.

I guess that's acceptable. If Windows has no events, there isn't anything to do but eat the cost.

Made what are hopefully the last batch of fixes and rebased on the latest master branch.

Thanks! Fantastic work getting this together!

Also, thank you for sharing your research and results! It does seem clear that WinRT events are the way that modern HDR should be implemented in Windows (to get AdvancedColorInfo events). Long term, maybe this will be an option for Godot. If someone else wants to take a stab at further optimizing this in a followup PR, I'm sure your notes will be very valuable!

For the reference, I have checked it while working on #116349 (using WinRT for TTS), and getting AdvancedColorInfo change events works fine on MSVC, but MinGW is missing windows.graphics.display.interop.h and corresponding lib (attempt to generate it from Windows SDK IDL result in non-functional code).