Open mitzsch opened 1 year ago
on this sample, when KMD reported HdrARGB10ScanoutSupport =1 & HdrFP16ScanoutSupport = 0, the runtime always send the FP16 format and scRGB color space to flip, why not ARGB10 and BT2020 color space?
As I know, for KMD it's always scRGB (709 FP16 linear with higher extends) with the fixed static metadata - ideally will be the same as that the display EDID indicate back to OS.
Since there have HdrARGB10ScanoutSupport and HdrFP16ScanoutSupport options, OS maybe can send ARGB10 and BT2020. And from spec described, there have two option for AP?(https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range) Option 1. Use FP16 pixel format and scRGB color space Option 2: Use UINT10/RGB10 pixel format and HDR10/BT.2100 color space
Besides, you said display EDID also have the definition of color space? Maybe the monitor doesn't support?
I just got a question regarding the Direct3D 12 HDR sample app. Actual metadata is only transmitted when the app is in fullscreen. I confirmed this with a hdfury arcana that shows the HDMI stream information. Is this behavior intended, where metadata is only forwarded in fullscreen mode, or is this a bug? Or to ask it differently what is needed for the windows compositor to actually forward HDR metadata?
This behavior is also present in other apps, like the video player mpv, that rely on the same api calls (like
IDXGISwapChain4_SetHDRMetaData
). The mpv video player transmits metadata only in fullscreen mode, like the HDR samples app.(tested on Windows 10 21H2, with a RTX3050 and a RX 580)