Dxvk: Overwatch hair/fur/fuzz rendering glitches

[tycho]

Hair seems to render very strangely in Overwatch for me, and I'm not sure why:

Each frame the hair changes, but it always has seemingly random transparent portions for some reason.

Software information

Overwatch. Tried "Low" and "Epic" graphics quality and got the same effect.

System information

• GPU: AMD Radeon RX Vega 64
• Driver: Mesa 18.3.3, RADV, LLVM 7.0.1
• Wine version: https://github.com/wine-staging/wine-staging/commit/b8de62375fa4be6abfa6c12c0c81002b3d4a75fd
• DXVK version: current HEAD @ https://github.com/doitsujin/dxvk/commit/7056425bbdf399edf98d75533b8c62ea985289e1 though I've seen this issue before and assumed it was something wonky with my setup.

Apitrace file(s)

... working out how to capture this right now. Will update in a few moments once I get it, but want to get this report in now before I lose my progress in writing this.

Log files

• d3d11.log: Overwatch_d3d11.log
• dxgi.log: Overwatch_dxgi.log

[tycho]

Also, just noticed this seems to not happen with the wine-provided d3d stuff, only DXVK.

The trace from "apitrace -a dxgi" looks like it's rather short, and I'm not sure why. I removed dxvk from the wine prefix and zapped the DLL overrides, but there's still only like 6 API calls recorded via apitrace? Overwatch.trace.zip

Maybe it's short because apitrace is spewing these a lot during the capture:

apitrace: warning: caught exception 0x80000004
apitrace: flushing trace
apitrace: warning: caught exception 0x80000004
apitrace: flushing trace
apitrace: warning: caught exception 0x80000004
apitrace: flushing trace
apitrace: warning: caught exception 0x80000004
apitrace: flushing trace
apitrace: warning: caught exception 0x80000004
apitrace: flushing trace
apitrace: warning: caught exception 0xc0000420
apitrace: flushing trace
apitrace: warning: caught exception 0x80000004
apitrace: flushing trace
apitrace: warning: caught exception 0x80000004
apitrace: flushing trace
apitrace: warning: caught exception 0x80000004
apitrace: flushing trace
apitrace: warning: caught exception 0x80000004
apitrace: flushing trace

[doitsujin]

IIRC this is a known LLVM bug on Vega, please try llvm-git.

[tycho]

@doitsujin Do you know which commits in llvm are relevant to this issue? Is there an upstream bug report I could look at?

[Kreyren]

@tycho i was told that LLVM 7.0.1 is causing those issues try LLVM 6.*

I don't have those issues on my end though..

Distro?

[tycho]

Arch Linux. I build my own LLVM and mesa though (among many other packages):

https://git.uplinklabs.net/steven/projects/archlinux/ec2/ec2-packages.git/tree/llvm/PKGBUILD
https://git.uplinklabs.net/steven/projects/archlinux/ec2/ec2-packages.git/tree/mesa/PKGBUILD

I'm working on getting the LLVM release_80 branch built. Hopefully mesa already has support for it.

[Kreyren]

@tycho Tested on gentoo on my end using AMD 7870 and LLVM 7.0.1 had no issues excluding frezes every few minutes. Your provided screenshot seems to output LLVM 7.0.1 maybe you miss some commits?

[tycho]

Currently using LLVM 7.0.1 from the release tarballs. Does your Gentoo ebuild have some extra patches on top?

[Kreyren]

Sending ebuild: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/llvm/llvm-7.0.1.ebuild

Seems to provide only documentation patch

Also uses sys-devel/llvm-common and sys-devel/llvmgold for runtime

Maybe you miss some dependency?

[tycho]

If I was missing dependencies I'd expect a more dramatic failure.

[Kreyren]

If I was missing dependencies I'd expect a more dramatic failure.

Depends on many variables, happend to me many times that software partially worked and didn't output any errors about missing dependency that caused the issues.

Btw. if you are using master or versions that would be considered insane for noob distros you can expect simmilar issues it usually lacks idiot-proof functions alike error for missing dependency.

EDIT: i can't write + more info

[doitsujin]

@tycho

Do you know which commits in llvm are relevant to this issue? Is there an upstream bug report I could look at?

No and no. Bugs in the AMDGPU backend are not reported to LLVM directly, but to Mesa. I remember there being a mesa bug report about this exact issue, but I can't find it right now.

@Kreyren please don't suggest anyone to use LLVM 6, it's an utterly broken mess that is only ever going to cause sadness and despair.

[tycho]

Yeah, wasn't going to consider rolling back LLVM. The only sensible route is rolling forward.

[Kreyren]

The only sensible route is rolling forward.

mad man o.o it may take some time untill upstream fixes issues alike.. i was running gentoo on master and make system-wide update non-stop.. it practically needs full time babysit and lots of patching.. If you are going this route i would suggest you to make a backup OS and systemrescuecd patches for chroot, etc..

[tycho]

Okay, just tested LLVM release_80 branch + mesa 19.0 branch. Looks flawless now.

[tycho]

mad man o.o it may take some time untill upstream fixes issues alike.. i was running gentoo on master and make system-wide update non-stop.. it practically needs full time babysit and lots of patching.. If you are going this route i would suggest you to make a backup OS and systemrescuecd patches for chroot, etc..

Why? It's just LLVM and Mesa. Worst case scenario X11 wouldn't start and I'd have to roll back.

[doitsujin]

Okay, just tested LLVM release_80 branch + mesa 19.0 branch. Looks flawless now.

Alright, thanks for reporting back. The respective stable versions aren't too far away anyway.