Do we actually get an R16G16B16A16_SFLOAT swap chain on the Vulkan side or is it R10G10B10A2? The D3D11 log should include the swapchain format.
Either way this is probably something for @Joshua-Ashton to look at. scRGB is more or less untested and known to be broken with Special K, but I don't have an HDR-capable setup to test things with.
It should work fine and looks correct in Control HDR and Cyberpunk (even though their scRGB is clamped to 709).
Are you calling SetColorSpace1, or relying on some implicit behaviour we do not implement?
How are you reproducing? If there is a build of your game in Steam and its ok for me to try that, please tell me the appid -> [email protected]
It's also worth noting that 75% brightness = 1.0 digital gain for HDR content on Deck OLED.
Thanks for the fast replies!
Are you calling SetColorSpace1, or relying on some implicit behaviour we do not implement?
We are not (at least not right now, I'll implement that to check to see if that fixes it).
We're currently relying on the (documented) behaviour that R16G16B16A16_FLOAT swapchains are automatically DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709.
If setting the color space manually does not solve the issue I'll send you an email.
Yeah we are not doing that rn. We should, I am going to sleep now so I'll do that tomorrow.
I was beaten to it =)
That also was the issue: manually setting DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709 solved the problem.
Should be fixed in current master, please let me know if there are issues with your use case.
I expect this change to fix it, but we will ship with explicitly setting the color space.
I'll try the old version of the game with new DXVK once I can easily get that on the Deck and let you know.
Side note that is completely unrelated to DXVK, but related to scRGB and might get a chuckle out of you:
I found a pretty severe bug in the Windows 11 compositor -- if any (sub)pixel of the FP16 frame you hand to the compositor has a negative value, it completely and statefully breaks the compositor's internal surface at that location. To the extent that displaying all other, unrelated applications is then also broken at those screen positions. Seems pretty wild for a user-space program to be able to do.
That really sucks given the only way to represent values out of the 709 gamut with scRGB is with negative values.
Nothing extracted yet.
When using a
R16G16B16A16_FLOATswapchain buffer for HDR, in Windows, the compositor expects scRGB color space (DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709).I.e. (1,1,1) should be about 80 nits, and 1000 nits is something like (12,12,12).
When presenting the same frame on the OLED Steam Deck, it is completely blown out (and the gamma is also way off).
Note: I'm not sure if this is actually a DXVK bug or a bug elsewhere in the display chain -- that's hard for me to tell. If I should report it elsewhere please let me know.
Software information
Unreleased game. But I really don't think this is a game-specific problem.
System information
Steam Deck OLED
I haven't included an apitrace or log, since I don't think it makes much sense or helps for this type of problem.