One of the restrictions for D3D11 is exclusive fullscreen support only. Moving forward with D3D12 support in Windows 10 we’ll hopefully be extending our offering to allow individual viewports to enable HDR output (Part of the “creators” update) as this will be essential for HDR content creation. I believe the Mac implementation already allows this. The support-levels are somewhat out of our control but we’ll hopefully implement support wherever possible.
For a D3D11 app on an Nvidia or AMD device:
r.HDR.Display.OutputDevice 5 // 1000 nit scRGB
r.HDR.Display.ColorGamut 2 // Rec2020
The “default” combinations in the settings system are just those that seem to cover all bases right now, but it’s fine to mix devices and gamuts or even expose those to end-users to let them decide. Enabling HDR on the display is an isolated step, after that it’s mainly swapping out tonemapping shaders to encode the data in different ways. Again, if you take a look at the above mentioned function you can see the common combos we’re supporting in this experimental release.
It’s worth noting that only experimental Nvidia D3D11 support shipped in the 4.15 release. If you’re after AMD support it is in Github now, it’s a small change you could likely integrate if needed. I can’t comment on a timeline for other platforms/features just yet though.
As a note: If you’re running a project with an options menu or similar already running with the GameUserSettings system, you can use the enable HDR option on those blueprint nodes (or C-side calls). That should handle automatically booting into HDR based on previous saved settings and falling back when booting with the HDR display unplugged, etc. The cvars are there as a way to give more convenient testing and manual control if you want it. 