please lessen HDR requirements

[madshi]

Hi there,

agsSetDisplayMode works for me to dynamically switch the TV into HDR mode. However, there are a number of nasty requirements:

• there must be a D3D11 swapchain, D3D9 is not supported
• the D3D11 swapchain must be 10bit, 8bit is not supported
• the D3D11 swapchain must cover the whole screen

If these requirements are not met, agsSetDisplayMode still returns success but does nothing.

I don't like these requirements at all. Please allow me to be the judge in which situation the TV is turned into HDR mode. Which should be the moment in which I call agsSetDisplayMode (with the appropriate parameters), regardless of whether there's any active D3D swapchain or not.

FYI, this is how the Nvidia HDR API works: I can simply switch the TV into HDR mode. Even for normal desktop applications. There's no requirement to have any active D3D swapchain at all. I'm aware of that the desktop, taskbar etc will look all funky in HDR mode, but I don't mind that, nor do my users.

If you absolutely feel the need to "protect" developers from switching to HDR mode while not being in 10bit fullscreen rendering mode, then I'd suggest that you add a flag/option to disable that "protection".

Thank you! :)

[gareththomasamd]

Hello madshi,

It sounds like you are not the typical use case of this feature.

1. The mechanism to switch to HDR mode is DX version agnostic so there might be an issue our side regarding DX9. We'll investigate but I can't make any promises for D3D9 support.

2. We only support 16 bit and 10 bit swapchains. Is there any point in supporting 8 bit given its limited range? What is your use case here?

3. A fullscreen swapchain is indeed required when the OS does not understand HDR. For Win10 Creators Update you can switch HDR on the desktop if you want to support non fullscreen HDR apps.

thanks.

[madshi]

Hi Gareth Thomas @amd,

and thanks for your reply. It's a refreshing change to have actual contact to an AMD dev! :) I wish I had this luxury for other issues I have with various GPU drivers...

I apologize in advance for the long reply. I hope you don't mind.

1. I believed D3D9's support for higher than 8bit swapchains to be rather shaky, I'm not sure if it works at all. So probably the issue is not D3D11 vs D3D9, but simply the bitdepth, because I'm always using 8bit with D3D9. Are you saying that AMD fully supports 10bit backbuffers for D3D9 with 10bit passthrough to the display? Maybe I need to give that a try!

2. My video renderer (madVR) has very high quality dithering algorithms built in, e.g. void-and-cluster ordered dithering, or even error diffusion via compute shaders. As a result, using 8bit works great even for HDR content. One good reason for 8bit HDR support is that HDMI 18Gbps runs out of bandwidth at 4Kp60 for 10bit RGB. And IMHO sending out nicely dithered 8bit RGB is better than 10bit YCbCr 4:2:2, because dithering is as good as invisible while chroma resolution loss can be quite visible in some situations. Furthermore, if the GPU converts to YCbCr, the TV won't know for sure which RGB -> YCbCr matrix the GPU used (e.g. for 4K is it BT.709 or BT.2020?), so there's a potential for introducing color errors when outputting YCbCr from the PC. Finally, if the GPU performs RGB -> YCbCr conversion, my nicely dithered pixels get further processed, which can't be good for quality. As a result I have a strong preference for always outputting RGB from a PC.

3. I'm aware of that the "HDR and Advanced Color" OS switch allows HDR for non-fullscreen HDR apps. However, to be brutally honest, I hate the OS switch with a vengeance, because it's a static switch. No user in his right mind is going to change the OS switch manually every time before and after he plays a HDR video (or game). That's a usability catastrophe! And no user in his right mind wants to drive his TV in HDR mode all the time, even when playing SDR videos/games. Which is why I'm very happy about the AMD HDR API, because it allows me to dynamically switch HDR on and off.

Now why do I want HDR for windowed apps? There are 2 reasons:

a. I have a "video test pattern generator" app for display calibration, which is directly supported by the major calibration software companies (like SpectraCal, ArgyllCMS, LightSpace etc). This test pattern generator in its latest version has an "HDR" button which is supposed to dynamically and immediately switch the TV into HDR mode. With the Nvidia API this works, even in 8bit windowed mode, with no active swapchain. With the AMD API nothing happens if the user presses the HDR button, as long as the application is in windowed mode, which might be confusing to the user.

b. Overall it feels better/nicer/more reliable if I can simply tell the GPU to switch into HDR mode immediately, with no questions asked. Currently, AMD requires me to fulfill all kinds of requirements before the HDR API works, and if the requirements are not met, the API still reports success but does nothing. That doesn't feel very reliable to me. I'd prefer a more straightforward API which simply does (immediately) what it's told instead of being picky about the circumstances.

Maybe you could add a "force" flag which bypasses all checks and simply switches into HDR mode immediately, regardless of bitdepth and swapchains? That would be a big improvement for my use case.

Thanks!

[gareththomasamd]

So your windowed HDR needs will have to be served by Windows10. We do not intend to enable HDR support in windowed mode beyond the native support in RS2.

When calling agsSetDisplayMode, we don't know the surface format so the actual change of mode is deferred until after the call, hence the function returning success even for unsupported swapchain formats.

Allowing 8 bit swapchain support is something we'll have to look into in a little more detail.

[madshi]

Thank you. Supporting 8bit would be a nice improvement for my users.