Still works fine on my RX 480. Please bisect the issue if you think this is a DXVK regression.
Please keep in mind that there is a game bug causing the image to be too dark on some systems when running above 60 FPS.
I don't have 60 FPS. What is "bisect the issue"?
https://git-scm.com/docs/git-bisect
In any case, I cannot reproduce the problem.
So, what should I do with 'git bisect'?
You need to bisect it and test different versions of DXVK.
So, I have to compile them? I tried to compile DXVK once and failed. Are there compiled builds between 0.96 and 1.0 available? I would test them.
Are you using the dxvk version that is shipped with proton or have you tried dxvk by placing it next to the game? Just to eliminate proton in this equation.
Both. It started glitching when I tried DXVK 1.0 almost two weeks ago. I had Proton 3.16-6 or 3.16-7 back then. I've been using 0.96 since that. But now Proton got updated, got DXVK 1.0, and that happened again. If I replace Proton's DXVK with v0.96, the game works fine.
You could try setting d3d11.relaxedBarriers = False in the config file.
Although that doesn't really explain why it works fine with 1.0 for most people.
I have bisected the issue and found https://github.com/doitsujin/dxvk/commit/915091b76b2de06d04a4de0b050001b8e7c88169 to be the breaking point. Reverting it fixes the issue on both RE2 and DMC5.
Should be fixed as of 032625882990ae843cbdcd526f3c72087ab31888.
I don't know why using shift instructions (even arithmetic shifts, which should be equal to signed division) breaks on Nvidia, but it does, and this commit works around the issue. Thanks to @Tk-Glitch for testing.
I can confirm I have the same issue as reported on a NVIDIA GTX 980 with latest Proton.
Yes, everyone on Nvidia has this issue, just read the comment above for a fix.
I've identified the compiler bug, and it is already fixed in the most recent Vulkan developer driver at https://developer.nvidia.com/vulkan-driver. It should be fixed in our next mainline driver release as well.
arithmetic shifts, which should be equal to signed division
Arithmetic shift of negatives is not equal to division. Division rounds to zero, shift rounds to negative infinity.
The numbers in question are guaranteed to be a multiple of 4 (and technically also guaranteed to be non-negative).
Wasn't this found to be a game bug when running at low frame rates anyway?
Well I'm sorry that I wasn't able to guess your hardware and framerate based on absolutely no information whatsoever...
The bugfix I made was only in the Vulkan SPIR-V compiler and had something to do with shared memory ordering. It's possible the DX compiler could have a similar issue, but it would be in a different part of the code base. But it's also likely it could be something completely different.
Was that a genuine driver bug though? The game is known to rely on undefined behaviour wrt workgroup shared memory, which has also caued issues with RADV in the past.
I don't actually know. The change I made was for a different app, where it was fixing a legitimate compiler bug, and the same fix also fixed this bug. So we never debugged this particular shader in detail.
proton 3.16-6x1 2019-03proton 3.16-8x1 2019-03
RESIDENT EVIL 2 / BIOHAZARD RE:2 (883710) worked fine with DXVK 0.96 but with DXVK 1.0 the image is very, very dark in-game. It reverts back to normal if I downgrade DXVK.
Software information
RESIDENT EVIL 2 / BIOHAZARD RE:2
https://store.steampowered.com/app/883710/
System information
Log files
steam-883710.zip