vo_gpu/d3d11: add support for configuring swap chain color space

[jeeb]

Now more or less brought to a relatively good state.

Enables among other things, the configuration of the PQ color space (BT.2020 primaries, PQ transfer function) for HDR.

1. Adds the concept of FBO color space into the rendering.
2. By default utilizes the color space of the desktop on which the swap chain is located.
3. If a specific value is defined by the user, it will be instead be utilized.
4. Additionally, signals the swap chain color space to the renderer, so that the render looks correct without having to specify target-trc or target-prim manually.
5. Due to all of the APIs being Win10+ only, will only work starting with Windows 10.

Initial things to do:

• Initial PoC.
• Moving relevant stuff under general d3d11 helpers.
• Sharing colorspace information (primaries, transfer function, HDR metadata) with the rendering stuff, and the renderer having its own colorimetry state.
• Checking the screen the window is on, and auto-detecting PQ+BT.2020-configured screens and making an (on/off/auto) option for PQ+BT.2020 swap chains, where auto sets a PQ+BT.2020 swap chain if content is HDR and screen is in PQ mode.
• Setting the output transfer function to PQ and primaries to BT.2020 if PQ+BT.2020 swap chain is enabled by default, to match render target.

Things to maybe do later:

• Pass on HDR metadata if available, pass on the calculated HLG value for HLG content.
• Warn user clearly if the screen connection is set to less than 10 bits with PQ+BT.2020.

Example usage for PQ on a non-PQ desktop: --d3d11-output-csp=pq --fs --fs-screen=N (the full screen stuff really isn't required since the compositor does seem to handle it nicely, but usually you want this).

Relevant example logs:

[vo/gpu/d3d11] Initializing SPIR-V compiler 'shaderc'
[vo/gpu/d3d11] Using Direct3D 11.1 runtime
[vo/gpu/d3d11] Maximum Texture2D size: 16384x16384
[vo/gpu/d3d11] D3DCompiler version: 10.0.18362.1
[vo/gpu/d3d11] Using DXGI 1.2+
[vo/gpu/d3d11] Queried output: \\.\DISPLAY1, 3840x2160 @ 8 bits, colorspace: 0
[vo/gpu/d3d11] Selected swapchain format 28, attempting to utilize it.
[vo/gpu/d3d11] Selected swapchain color space 12, attempting to utilize it.
[vo/gpu/d3d11] Swapchain capabilities for color space 12: normal: yes, overlay: no
[vo/gpu/d3d11] Swapchain successfully configured to color space 12!

Resolves #5237 , #5161

[Doofussy2]

This would be great to add. Especially now that HDR passthrough can be operated dynamically, when using an Nvidia GPU. Are there plans to further this?

[Doofussy2]

I finally got around to using the test build. It works very well. The display switches to HDR10 when in full screen and reverts when windowed. I haven't experienced any issues, so far. Well done @jeeb.

One wrinkle. If I use --scale=ewa_lanczossharp, the picture is distorted. I have to add --scale=bilinear to my HDR auto profile to counteract it, then it plays correctly.

[Doofussy2]

What this doesn't do is enable 10 bit, like @rossy has in his test build in this thread.. Is it possible to incorporate that?

[   0.611][v][vo/gpu] Reported display depth: 8
[   0.611][v][vo/gpu] Texture for plane 0: 3840x2160
[   0.612][v][vo/gpu] Texture for plane 1: 1920x1080
[   0.612][v][vo/gpu] Testing FBO format rgba16
[   0.612][d][vo/gpu] Resizing texture: 16x16
[   0.612][v][vo/gpu] Using FBO format rgba16.
[   0.614][v][vo/gpu] Resize: 3840x2160
[   0.614][v][vo/gpu] Window size: 3840x2160
[   0.614][v][vo/gpu] Video source: 3840x2160 (1:1)
[   0.614][v][vo/gpu] Video display: (0, 0) 3840x2160 -> (0, 0) 3840x2160
[   0.614][v][vo/gpu] Video scale: 1.000000/1.000000
[   0.614][v][vo/gpu] OSD borders: l=0 t=0 r=0 b=0
[   0.614][v][vo/gpu] Video borders: l=0 t=0 r=0 b=0
[   0.614][v][vo/gpu] Reported display depth: 8

jeeb mpv log.txt

[   4.607][v][vo/gpu] Reported display depth: 10
[   4.608][v][vo/gpu] Testing FBO format rgba16
[   4.608][d][vo/gpu] Resizing texture: 16x16
[   4.608][v][vo/gpu] Using FBO format rgba16.
[   4.609][v][vo/gpu] Resize: 3656x2057
[   4.609][v][vo/gpu] Window size: 3656x2057
[   4.610][v][vo/gpu] Video source: 3840x2160 (1:1)
[   4.610][v][vo/gpu] Video display: (0, 0) 3840x2160 -> (0, 0) 3656x2057
[   4.610][v][vo/gpu] Video scale: 0.952083/0.952315
[   4.610][v][vo/gpu] OSD borders: l=0 t=0 r=0 b=0
[   4.610][v][vo/gpu] Video borders: l=0 t=0 r=0 b=0
[   4.610][v][vo/gpu] Reported display depth: 10
[   4.610][d][vo/gpu] Resizing texture: 3840x2160

The full log is too big to attach

This is needed for SDR 10 bit.

[ghost]

@jeeb Maybe merge what you have, since our last change was over a year ago, and the TODO on the top is full of harder things on top of it (like passing through the video HDR info). Or just close it as abandoned if that's the case.

[jeeb]

Just pushed the stuff updated to my current state. Will rebase and make it prettier tomorrow. :)

At this point, it's looking pretty good. The ra_fbo warning message is just in a place that will spam warnings. A lot. So that most likely needs a tweak.

[jeeb]

The spam has now been fixed and it warns you once:

[vo/gpu] One or more colorspace value is being overridden by user while the FBO provides colorspace information: transfer function: (dst: hlg, fbo: pq), primaries: (dst: bt.2020, fbo: bt.2020). Rendering can lead to incorrect results!

[Doofussy2]

I'm eagerly awaiting this. Hopefully it gets rolled into the next master.

[rossy]

I don't know about colour stuff, but I'm worried this might change the default behaviour for Windows 10 users who don't use HDR/Windows HD Color. Even though Windows specifies the colourspace of each monitor, RGB_FULL_G22_NONE_P709 is likely the value it uses when it doesn't really know, since there's no "unknown" value in the enum. As I understand, this will make pass_colormanage use 2.2 gamma instead of just copying the source gamma, which is what the old "auto" behaviour did. Since the old "auto" behaviour was there for a reason (to match user expectations?) I wonder if we should change it.

Apart from that, this looks good.

[rossy]

LGTM. Thanks for the changes.