doitsujin
Darkened colors with Reshade HDR on 2.6
Colors are very dark when using lilium's inverse tonemapping with Reshade's Auto HDR addon on 2.6. This was not an issue on 2.5.3. This is a comparison of before and after replacing the DLLs from 2.5.3 to 2.6 with no other changes made to anything and no config file, simply replacing the 2 DLLs and deleting the cache:
Do you mean you are having a issue with a dxvk fork? If so you should report the issue at their tracker.
I’m not using any fork, this is with the latest release from here. I’m just reporting a change in behavior with HDR between 2.5.3 and 2.6. RTX HDR works as intended, I will test other methods in the morning.
What is "lilium's inverse tonemapping" ? It's a generally a good idea to pretend that we know nothing about any external project or game that is having issues. Then make a more detailed issue explanation based on that assumption.
It uses reverse tone mapping to convert SDR image to HDR. Similar to Windows Auto HDR and Special K.
I assume it is from this repo https://github.com/EndlesslyFlowering/ReShade_HDR_shaders
Yes, I should have linked it. My bad. It’s in the official repository as well I believe.
So what does one need to do to reproduce this? Also please post a log.
Also, is this D3D reshade or Vulkan reshade? If Vulkan, this is probably another fallout from the swapchain format change, which would make this not our bug.
But I guess since pretty much every single third-party overlay is just plain broken, we'll have to find a workaround anyway.
If you're on Nvidia, try the below
https://www.pcgamingwiki.com/wiki/Nvidia_Profile_Inspector#Layer_Vulkan.2FOpenGL_on_DXGI_swapchain
In the latest NV inspector it should look like this
It is vulkan reshade, to reproduce just install the addon version of the latest reshade and in the installer select “lilium_inversetone_mapping.fx” under “Reshade HDR shaders by Lilium” and on the addon screen select “AutoHDR by EndlesslyFlowering” Make sure the CSP_OVERRIDE is set to “ CSP_SCRGB”. Changing the flags in profile inspector had no effect
The AutoHDR add-on only hooks d3d11 and d3d12. In the case of dxvk it usually hooks the Vulkan->D3D interop swap chain provided by the AMD or Nvidia driver if ReShade is installed for Vulkan. That would be outside of dxvk's scope.
Here are the logs: ACOdyssey_d3d11.log ACOdyssey_dxgi.log
how are you installing ReShade? for Vulkan or not?
Does this build here solve the problem? https://github.com/doitsujin/dxvk/actions/runs/13906109574/artifacts/2766761971
The AutoHDR add-on only hooks d3d11 and d3d12. In the case of dxvk it usually hooks the Vulkan->D3D interop swap chain provided by the AMD or Nvidia driver if ReShade is installed for Vulkan. That would be outside of dxvk's scope.
I installed it for Vulkan. Do you know what may have stopped it from working in the latest release? I probably should have brought this up on your tracker.
Does this build here solve the problem? https://github.com/doitsujin/dxvk/actions/runs/13906109574/artifacts/2766761971
Sadly, it did not
Just wanted to add that RTX HDR works as well as Windows Auto HDR with Lilium’s SDR TRC fix, so it is likely some interaction between the new release and the reshade addon or that specific shader.
ok, I'll try again: How do I reproduce this locally?
I don't know what any of these words mean, I don't know where you're getting your Reshade from, I don't know how you're configuring it, ... - again, please don't assume that we're experts on third-party tools that are generally not even used on our primary target platform.
ok, I'll try again: How do I reproduce this locally?
I don't know what any of these words mean, I don't know where you're getting your Reshade from, I don't know how you're configuring it, ... - again, please don't assume that we're experts on third-party tools that are generally not even used on our primary target platform.
-Go to https://reshade.me/ and click "Download" and "Download Reshade 6.4.1 with full add-on support" -Point the installer to whatever game executable you have DXVK installed with -Select Vulkan -On the effect selection screen click "Uncheck all" and scroll down to "Reshade HDR shaders by Lilium" and select "lilium_inversetone_mapping.fx" -On the add-on screen select "AutoHDR by EndlesslyFlowering" and finish the installer -In game press the home key to open the overlay, skip the tutorial and check the effect from before -In the effect configuration panel change CSP_OVERRIDE to "CSP_SCRGB" and press enter
ok, I'll try again: How do I reproduce this locally?
I don't know what any of these words mean, I don't know where you're getting your Reshade from, I don't know how you're configuring it, ... - again, please don't assume that we're experts on third-party tools that are generally not even used on our primary target platform.
this is outside of dxvk's scope. the AutoHDR add-on grabs the Vulkan->D3D interop swap chain provided by the driver and modifies that. I have talked with @KoKlusz before about this after the 2.5.2 release when it stopped working for him and it was related to Nvidia force disabling the interop swap chain for unknown reasons with the 2.5.2 release. I think 2.5.3 may have fixed that? don't remember. this sounds similar but apparently is not the case. Even if does not grab the interop swap chain it would grab the original D3D swap chain and it should work. Maybe it even grabs both. I haven't tested that yet. But I will later.
I think 2.5.3 may have fixed that? don't remember.
The only thing 2.5.3 really did is give users an option to allow full-screen exclusive again, since forcing it off by default in 2.5.2 led to a bunch of complaints.
Either way, I narrowed this particular regression down to the swapchain rewrite that happened in 2.6, but I have no idea what part of it could be causing it, from a Vulkan POV the swapchain looks the same as it did in 2.5.3. The only thing I can say with some degree of certainty is that an sRGB <-> linear conversion is getting lost somewhere along the way.
The only thing 2.5.3 really did is give users an option to allow full-screen exclusive again, since forcing it off by default in 2.5.2 led to a bunch of complaints.
right that did not fix it.
anyways I can't get this to work at all on my AMD gfx card. always getting this error (from the ReShade log):
vkCreateSwapchainKHR failed with error code -13. -13 is VK_ERROR_UNKNOWN. Even went back to 2.5.1, so not a 2.6 issue.
The only thing I can say with some degree of certainty is that an sRGB <-> linear conversion is getting lost somewhere along the way.
that actually kinda makes sense. it seems 2.6 makes SRGB format swap chains instead of UNORM swap chains. if the swap chain format is overwritten SRGB does not get applied anymore (if the game relies on that). In my shader I linearise that image data and then further process it. So it would be linearising already linear image data, which would explain the overly dark image. @Maidenfan724 you can try using "linear (scRGB)" or "linear with SDR black floor emulation (scRGB)" as "input gamma" in the inverse tone mapping shader.
also just to be clear: I do not recommend using the AutoHDR add-on like that due to it possibly seeing multiple swap chains.
What's weird here is that current master changed it to always creating UNORM swapchains because using sRGB formats broke RTSS, and yet the issue remains the same.
Apparently, what's causing the problem right now is that we're creating an UNORM swapchain but use an SRGB view format to draw to the image (which is legal with VK_KHR_swapchain_mutable_format). I don't really understand why this would be causing issues though.
Commenting out these lines seems to solve this: https://github.com/doitsujin/dxvk/blob/14ac1eb1294bd7f7a5510430b27380304f59e708/src/dxvk/dxvk_presenter.cpp#L766-L775
Doing so makes us pass UNORM content from the game directly to the vk swapchain, otherwise we'd render to an sRGB view and do an srgb->linear pass in the shader that draws to the swapchain image. This may seem redundant, but the idea behind this change was to allow our own HUD as well as software cursors to be blended correctly without requiring a dedicated render target.
But again, I really don't see why this would be problematic - unless something is changing the Vulkan swapchain format behind our back without telling us.
It also doesn't help that RenderDoc is just crashing on my Windows setup, not sure if it's due to the Reshade layer or not.
But again, I really don't see why this would be problematic - unless something is changing the Vulkan swapchain format behind our back without telling us.
that could be the add-on's doing... though it is written to only work on d3d11 and d3d12. if the add-on sees the swap chain before dxvk does anything with it the format changes should be visible inside of dxvk. if it only sees the interop swap chain dxvk probably has no idea what is happening. weird would be if the interop swap chain format also influences the Vulkan swap chain format. no idea what happens if the add-on sees 2 swap chains and if ReShade even hooks both.
Yeah, in either case, using a different rendering format should be entirely transparent, but evidently that is not the case.
#4779 should work around this. Not that I'm a particularly big fan.
if you want to test some more, here is an updated version of the add-on (64bit version, if you need the 32bit version let me know) that has logging build in when changes happen (it gets written to the reshade log file): AutoHDR.zip
looks like this:
23:47:44:111 [22596] | INFO | [AutoHDR] [DXGI]: DXGI Output supports: DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020
23:47:44:113 [22596] | INFO | [AutoHDR] [DXGI]: swap chain format updated to DXGI_FORMAT_R16G16B16A16_FLOAT
23:47:44:113 [22596] | INFO | [AutoHDR] [DXGI]: DXGI swapchain colour space DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709 set
23:47:44:115 [22596] | INFO | [AutoHDR] [ReShade]: ReShade colour space DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709 set
Yeah, in either case, using a different rendering format should be entirely transparent, but evidently that is not the case.
#4779 should work around this. Not that I'm a particularly big fan.
I contacted @crosire about it. maybe we can figure something out.
ok it seems the add-on changes the format for APIs that are not d3d11 and d3d12. I thought it did not but it does because it does not check what API is active for every function. I am going to change that, hopefully that works.
AutoHDR.zip @doitsujin can you test this version? it should not touch anything that is not d3d11/d3d12, while it still works for d3d11/d3d12 (just tested it) the current release version modifies the Vulkan back buffer and swap chain format too, though the add-on was never intended to be used with Vulkan.
I'll wait on you to test it before I upload it as a new release, so we can make sure.
on a side note: This was never a dxvk problem. dxvk should never care what outside modifications do to it. Even if I left it as is, swap chains that use the sRGB format are covered in my inverse tone mapping shader for ReShade.
Can't get that version to run, doesn't look like we get working a device / swapchain at all. This is very much still using the non-recommended way of using the addon though since that's what OP originally reported, not sure if that's expected or not.
(attempt number 2 at this because I wanted to rule out pebcac on my end)
What is the recommended method to use the addon? I can’t seem to find clear documentation. Hopefully my ignorance can at least point you more knowledgeable folk in the direction of a solution, I appreciate the effort. Apologies for not using the proper channels.