Does adding anv_force_filter_addr_rounding=true help? Add it as a launch argument.

Does adding anv_force_filter_addr_rounding=true help? Add it as a launch argument.

I'll try this as well once I have time. I'm a bit busy so I can't yet but I'll let you know if this fixes it for me.

I have noticed that there are some cutscenes which the character's facial expressions freeze and they start talking without moving their lips or keeping their eyes closed after blinking.

I could be wrong here, but I'd hazard a guess that this happens in Windows too and is just because the developers didn't have the time to animate some facial expressions.

If I'm not mistaken DXVK_ASYNC in itself can cause graphical glitches, and INTEL_DEBUG=stall is likely forcing async to not work as intended.

Well DXVK_ASYNC simply doesn't do anything because it doesn't exist. Even less so if you use D3D12 because DXVK is barely involved there. Please. Stop. Throwing. Useless. Env vars. At. Everything.

Like I said in the original post, I don't know what causes the issue nor exactly where to report it. I added different environment variables and configuration options that were suggested online without knowing what they do as trial and error because I didn't want to create an unnecessary issue. These worked until the new game update when I couldn't find a clear solution for a while.

If I'm reading the code correctly then INTEL_DEBUG=stall actually just inserts barriers between all commands, which indicates some sort of GPU synchronization bug either in dxvk or the driver.

To be clear I was not the one who tried adding INTEL_DEBUG=stall, and that wasn't what fixed the issue for me. I will try to see if that option changes anything though.

Would be good to re-test current dxvk master here since I rewrote a bunch of the sync code and fixed some potential bugs in the process, but these types of things aren't exactly easy to debug, especially w/o a way to reproduce.

I'll test this with the latest version as soon as I can. I will also try to find more clear reproduction steps.

It's not entirely clear from the comments if the flickering happens in DX12 mode as well, if so then I'm more inclined to say driver issue if it's exactly the same bug.

I believe the game uses DX12 by default unless you add the -dx11 option but I am unsure. It could be that this issue is only caused by DX12 and therefore isn't related to DXVK but I don't have enough time to test this yet, however I should be able to later. Currently I made multiple changes including adding -dx11 that have mostly made the problem go away (I've noticed a few instances of flickering but nothing like the original issue), but I need to see if -dx11 alone fixes it. I didn't realize this until some time after I made the post and learned about the -dx11 option after making some other changes as well, so I don't know which of them fixed it.

I decided to give this another try today because I had some free time and I can't find any way to reproduce this issue at all anymore, whether with DX11 or DX12.

If I can find some circumstances that can repeatedly reproduce this with DX11, I'll reopen the issue. If @TheEndProd still experiences this then they could reply and I could reopen the issue, otherwise I don't have any idea what caused this.

Hello! I've started to expirience this issue today, after 3.1 update, at first I thought it was mesa-git messing things up(I use git one because it allows for xess in this game) so I rolled back to the stable branch, but it didn't help. I use cachy os and arc b580, this problem did occure before for me, but only with cachyos proton, with protonge it worked fine. I've tried to launch with this flag INTEL_DEBUG=stall and the issue was gone, but my performance was basically halved.
This is without the flag and with glitches

And here it is with the flag, the issue is gone but performance suffered significantly

Just to clarify, I understand that performance decreased because now GPU is waiting a lot, what I meant by "Any solution" is there any fix to the texture problem, without making my gpu wait for every draw?

Also, the issue only present in dx12, with dx11 and dxvk the problem is absent. Sorry for writing it here since it is dxvk repo, but the issue I face is exactly the same, so I wanted to know if there is a solution

Can you reproduce this with normal Valve Proton? If so please report it there and also link to this issue given it has background information.

Also, I have no idea how to fix your issue. It just stopped on its own for me after a while. Using DX11 is probably the best solution until there's another solution available.

Can you reproduce this with normal Valve Proton? If so please report it there and also link to this issue given it has background information.

Also, I have no idea how to fix your issue. It just stopped on its own for me after a while. Using DX11 is probably the best solution until there's another solution available.

I actually solved the problem, the reason why it appears is something to do with shader hash and how wuwa doesn’t insert uav barrier before light grid injection, which on intel cards starts before “clear” is finished, causing the flicker of light shaders. It’s solved by forcing the barrier by hand, but to do this we have to know a shader hash of light grid injection.

The reason why it stops is because there is a kind person who also plays the game on b580 and he pushes merges to vkd3d every time the game updates, but it’s not a permanent fix because every time there is a major version update, shader hash changes, so he has to redo it every time manually. To fix the issue you can either wait for vkd3d update, but it takes time, plus the said person might stop playing the game and pushing merges with new shader hash, or how I fix it now, is using vkd3d proton fork from said persons git with fix, building it on my system, making a custom copy of proton which I use to play the game, in my case cachy proton, and launching the game with it, at least until vkd3d updates and proton with which I play.

You can read more about it here: https://github.com/HansKristian-Work/vkd3d-proton/pull/2773

Can you reproduce this with normal Valve Proton? If so please report it there and also link to this issue given it has background information.
Also, I have no idea how to fix your issue. It just stopped on its own for me after a while. Using DX11 is probably the best solution until there's another solution available.

I actually solved the problem, the reason why it appears is something to do with shader hash and how wuwa doesn’t insert uav barrier before light grid injection, which on intel cards starts before “clear” is finished, causing the flicker of light shaders. It’s solved by forcing the barrier by hand, but to do this we have to know a shader hash of light grid injection.

The reason why it stops is because there is a kind person who also plays the game on b580 and he pushes merges to vkd3d every time the game updates, but it’s not a permanent fix because every time there is a major version update, shader hash changes, so he has to redo it every time manually. To fix the issue you can either wait for vkd3d update, but it takes time, plus the said person might stop playing the game and pushing merges with new shader hash, or how I fix it now, is using vkd3d proton fork from said persons git with fix, building it on my system, making a custom copy of proton which I use to play the game, in my case cachy proton, and launching the game with it, at least until vkd3d updates and proton with which I play.

You can read more about it here: HansKristian-Work/vkd3d-proton#2773

Thanks for the information ^^