Death Stranding: Director's Cut crashes if HDR was last enabled in-game and CheckColorSpaceSupport reports support for HDR but it is not globally enabled in DXGIOutput::GetDesc1's ColorSpace.
It seems safer to just lock HDR behind an option to avoid any teething issues like this. It sucks, but it also makes sense in a way.
vkd3d-proton 2.8 released last year with support for the new swapchain
interface.
No need to keep support for this legacy interface hanging around when
it complicates adding DxgiOptions support to the swapchain.
Unreal Engine 4 titles use AGS/NVAPI to try and enable
HDR globally.
They can key this off IDXGIOutput::GetDesc1's ColorSpace
being HDR10.
Many of these UE4 games statically link against AGS.
This is a problem as when UE4 tries to enable HDR via AGS,
it does not check if AGSContext, and the display info etc
are nullptr unlike the rest of the code using AGS.
So we need to special-case UE4 titles to disable reporting a HDR
when they are in DX11 mode.
The simplest way to do this is to key off the fact that all
UE4 titles have an executable ending with "-Win64-Shipping".
We check if d3d12.dll is present, to determine what path in
UE4 we are on, as there are some games that ship both and support HDR.
(eg. The Dark Pictures: House of Ashes, 1281590)
Luckily for us, they only load d3d12.dll on the D3D12 render path
so we can key off that to force disable HDR only in D3D11.
Sometimes we can't get an EDID if things aren't plumbed fully, or some displays just have broken EDIDs.
This accounts for both of those cases by using some dummy data if we are missing information.
Fixes value reporting to match Windows on common displays such as LG OLEDs.
Adds the ability to punt the global colorspace into HDR from SetColorSpace1.
We have no way of checking the actual Windows colorspace as the
only public method for this *is* DXGI which we are re-implementing.
So we just pick our color space based on the DXVK_HDR env var
and the punting from SetColorSpace1.
We might expand on this in future, but this is good enough for an
initial implementation.
FEX would like clean symbols for experimenting with making thunks down the line.
We also just shouldn't be exporting a bunch of random crap -- sadly -fvisibility=hidden doesn't help with a bunch of stuff :(
For reference, RADV also does this.
Doesn't appear to match Windows behaviour, but there may be scenarios
when we can't query the current monitor. Statistics still need to be
consistent in this case.
See #2933.
This breaks things for 32-bit, but it really shouldn't. My hypothesis currently is that the .lib generated is bogus, but the exports in the actual DLL are correct.
