Allow querying HGIG HDR metadata for outputs

[magcius]

The HGIG recommendations suggest exposing three fields to game developers to let them best do tonemapping in HDR: MaxFullFrameToneMapLuminance (MaxFFTML), MaxToneMapLuminance (MaxTML) and MinToneMapLuminance (MinTML).

DXGI already supports querying these values from an IDXGIOutput6, however Vulkan doesn't seem to expose the same functionality yet. Thus, it's difficult to retrieve the display-specific parameters for correct HDR tonemapping.

Note that Vulkan does have support for setting application-provided SMPTE ST.2086 HDR metadata, but this approach is discouraged, because TVs and display environments have not provided consistent display tonemapping in response to this metadata. See the note / remarks on the equivalent DXGI functionality

[linyaa-kiwi]

Thanks @magcius . The Vulkan System Integration TSG will begin discussing this tomorrow.

[alecazam]

The hdr metadata extension seems undefined as to it's application. AMD only sets this in a FSE HDR environment where the app has taken over control of the display. But Win10/11 have moved to borderless window now, so that it works more like macOS and the gui continues to work.

[linyaa-kiwi]

@alecazam IIUC, are you saying that VK_EXT_hdr_metadata no longer works at all in Windows 10/11?

[alecazam]

I have no idea. I haven't seen the extension do anything in a windowed or borderless windowed config. DXGI has already established those settings, and so I assume the Vulkan swapchain just sends off our HDR10 data directly to the DWM, or using the fast-flip model directly to DXGI and to the display. HDR seems to be working correctly.

The docs on this extension say to look at the spec, and then the spec says that details on the extension are outside of the Vulkan spec. And there is no HDR Vulkan sample trying to handle HDR on multi-mon on Windows. Most indicate that the entire Vulkan swapchain should be replaced with a shared DXGI framebuffer.

I assume this extension only applies to Fullscreen Exclusive which has been phased out by Microsoft. Windows Store apps can't change monitor resolution or refresh. The system (Windows and gpu control panel) should be handling all this. But again without real documentation or samples, I have no idea what this extension even does. DXGI supplies all the data needed to configure this. There was another setting for local-dimming in the one AMD GpuOpen sample that I found. But again, this was back when freesync only worked in FSE mode.

https://gpuopen.com/learn/using-amd-freesync-2-hdr-color-spaces/ https://gpuopen.com/learn/amd-freesync-premium-pro-hdr-sample/

[magcius]

I don't believe DWM on Windows does anything with the SMPTE ST.2086 metadata during its compositing, which indeed means that at most, the metadata could be sent down the wire for the TV to do tonemapping with, but TVs do not have consistent handling of that metadata.

That said, you don't need to send any HDR metadata. For now, if you know your display's MaxTML, which you can query using DXGI, or by running an application like VESA's DisplayHDR Test, you can test your engine by doing your tonemapping relative to those levels.

Ideally, Vulkan would let us query the monitor's MinTML/MaxTML/MaxFFTML directly, but it's not strictly necessary. Most games have their own calibration step to find MinTML/MaxTML/MaxFFTML anyway.

[alecazam]

DXGI also lies on my Samsung M8 and reports 1500 nits on what is a 400 nit monitor with a single backlight. When I adjust it with the Sony HDR setup for PS4, it get 477 nits passed down. My Tempest 1200 nit monitor with miniLED local dimming reports 1200. So I'm not sure what to believe on the HDR metadata that I obtain. But yes, we tonemap to those levels.

[magcius]

The HDR metadata reported by the display is an optional EDID block (CTA-861-G section 7.5.13, HDR Static Metadata). The solution recommended by HGIG is to have a fallback database of TVs, and a calibration mechanism in case the data is missing.

I believe you should be able to use the Windows HDR Calibration app to configure the MinTML/MaxTML/MaxFFTML values reported by DXGI.

[linyaa-kiwi]

Inside Khronos, we are actively discussing solutions to this problem with a renewed focus. We agree that this is an important problem that needs to be solved.

[MarijnS95]

For completeness, issue #1787 requests the same feature and can be closed as well when this is implemented and resolved.