Different rendering results due to different, but valid driver behavior - solvable by DXVK?
Apps have no way to know the implementation-dependent depth bias values unfortunately.
@aufkrawall just so happens that I discussed that with Samuel already as well. Right now there's no way at all to address this problem, other than by adding driver hacks which I'm not keen on doing - especially since they aren't really documented either. TL;DR can't do much about it.
It appears that D3D11 wants the scaling factor to be 1 though (i.e. no scaling).
Maybe we could force the factor to be 1 for DXVK only?
I'm really not a fan of app-specific hacks though...
Maybe a new vulkan extension, which lets the app specify the depth bias value it wants, would help?
Seems this has stalled?
There's nothing we can do without some sort of Vulkan support, which is already being discussed.
Not intending to nag anyone, but situation seems unchanged with recent mesa git-master (small shadows "missing" vs. native/amdvlk). :(
There's still no way to fix this properly.
Ok.
@hakzsam Since the efforts to get it into a clean extension aren't exactly rushing ahead, would it be possible to implement an env variable in RADV to make it calculate depth bias like it does with your patch on the freedesktop tracker? Then at least one wouldn't have to patch Mesa to get correct shadow rendering in DXVK. :)
There was https://cgit.freedesktop.org/mesa/mesa/commit/?id=8a47422d9778056b2263d5f253fab49dfed91486
Seems to look ~identical now vs. amdvlk (at least in Hitman 2) :)
This probably can be closed now?
Edit: Also testing HotS right now...
Yep, they are the same too :+1: :
Nothing extracted yet.
Samuel Pitoiset explained to me that at least in this particular shadow map example, differences between drivers are to be expected due to the Vulkan spec:
https://bugs.freedesktop.org/show_bug.cgi?id=109599
Is there the possibility for DXVK to unify the result among drivers in such cases?