Does this repro for you when actually replaying the trace (i.e. wine d3dretrace [...].trace with dxvk set up in the prefix)? It looks perfectly fine on my RDNA2, and I've never seen anything like this in game either, although I haven't really been playing much lately.
Edit:
info: DXVK-LOW-LATENCY: v2.7.1-3-521
please try an actual upstream build (idk this or whatever if you don't want to build yourself), we can't really support third-party forks.
Didn't know that. I'll have to clear out my launch options and try again, thank you. I don't know much about actually replaying traces myself, but I'll keep looking into it.
Here's the trace for WINE 11.4 (https://github.com/rankynbass/unofficial-wine-xiv-git) using the dxvk build you linked above. Still looking into playback.
https://mega.nz/file/RV5jST5Y#lHJNFEq1kJqIipP71vBcqjz9MA6XpV1yjIH4YVlTRqI
Closing this for now as apparently I can just replace the dxvk dlls in a protonprefix with 2.7.1 stable (or any other arbitrary version) as a workaround (ref https://github.com/netborg-afps/dxvk-low-latency/blob/low-latency-framepacing/README.md). Might come back to this when I know more about what I'm doing regarding troubleshooting. Thank you very much for the initial response, though.
actually one thing you could try is RADV_DEBUG=nodcc,nohiz and see if that does anything (besides reducing perf), this bug does look like some sort of dcc corruption, but no idea why that kind of thing would happen here or why it's seemingly an RDNA3-exclusive. The minimap is just rendered as a separate pass close to the end of the frame, not exactly rocket science.
sadly, no dice on Proton-GE latest. I'll keep twiddling around with it sometime. being some kind of tech-exclusive would explain why it's so irritating to repro
This started appearing for me when I switched to https://github.com/GloriousEggroll/proton-ge-custom yesterday. I'm also using xivlauncher-rb. I tried replacing dxvk with the contents of "Version 3.0" released three days ago, and it didn't change anything.
The launcher also allows for selecting a version, and I tried 3.0 from there and got the same results.
It looks like it's... pulling tiles from the wrong area of the... framebuffer?
Are you also on RDNA3? Has anyone ever managed to reproduce this with the apitrace from https://github.com/doitsujin/dxvk/issues/5606#issuecomment-4340057458 ?
Again, it's the most basic-ass renderpass in the entire game and it clearly works fine on other hardware, no idea what's happening here. Can't even plausibly be a sync bug if disabling DCC doesn't help. Can't be depth/stencil related because there's no depth/stencil at all. There's a proper barrier right before the minimap is drawn onto the swapchain as well. It's so weird.
I'm going to re-open this just for the fact that someone else actually has the issue I'm referencing, and I'm not just losing my mind. More points of reference please 💀
Yes, I'm on RDNA3. Fedora F44. I'm running under Wayland, and the issue appears whether I'm running in Xwayland or Wayland mode.
@Mokura what makes you think it's a DXVK problem and not a problem with Wine? I'm only experiencing it when I use https://github.com/GloriousEggroll/proton-ge-custom -- I posted here because this was the only reference I've found to this issue, and I'm not yet convinced that the issue is one with DXVK.
@xobs I've seen it happen regardless of whether I use WINE or Proton, or even whose build of WINE or Proton I pick. Anything past 2.7.1 stable gives me the minimap issue. I haven't tried 3.0 yet because I was working around it via replacing the dxvk in more up to date Proton folders with 2.7.1 with little issue, and if it ain't broke. I should give it a try soon.
If it's a driver issue, should I file an issue on mesa's repo? And would being on mesa-git rather than being on stable mesa cause any (additional?) issues? I'll test the build when I next get the chance, though.
Well the question remains whether replaying the apitrace actually reproduces the problem, otherwise Mesa folks won't be able to do anything either.
EDIT: Important note I forgot to mention: these tests were done with main branch DXVK.
Preliminary testing with the first part of the dungeon used in apitrace. Everything run using Wine/Proton's Wayland driver.
proton-cachyos 11.0-20260602 with dxvk 3.0 release inserted: no minimap corruption so far
unofficial-wine-xiv 11.4 with dxvk 3.0 stable release selected in launcher setup: no minimap corruption so far
... Your guess is as good as mine at this point. I'll keep running with proton (and future versions of proton that ship with dxvk 3.0+) to see if I can reproduce the issue again. 🤷♀️
I've been having rendering issues on my 7800X3D/9070 XT setup for a little over a week now as well. Like doitsujin said, it seems like it may be a mesa issue. I've occasionally experienced severe artifacting like the video attached, but occasionally it presents as small chunks of flickering pixels instead.
I haven't gotten to do very much thorough testing, but I've blown this system away a couple times now with no changes. I've also verified this behavior (or similar) doesn't occur on my Windows partition, so I don't believe it's a hardware issue.
I can edit my comment with more version details later today if it'd be more helpful, but IIRC I'm just running Proton Hotfix on Mesa 26.1.4. Video attached is a pretty good representation of the most severe artifacting I've experienced so far.
https://github.com/user-attachments/assets/26104c82-8a7f-45b3-861d-a3b92462edfb
That seems like a different issue
Does RADV_DEBUG=fullsync fix this?
Honestly kinda looking like some sort of barrier isn't doing what it's supposed to, but since no one can reproduce this in a way that's actually debuggable...
Better yet, can anyone test this branch:
https://github.com/doitsujin/dxvk/tree/no-unsync-renderpass
I haven't been able to reproduce the bug this evening unfortunately (or fortunately I guess), but I did see some activity on Proton that may have solved my issue. I did try running with RADV_DEBUG=fullsync earlier and saw no errors (outside of a lower framerate), but I believe the Proton changes were already live by the time I got to test.
I can still try the no-unsync-renderpass branch if you'd like, but I'm not sure whether my experience would be valuable if I can't reproduce the issue again. I'll keep testing my system in the mean time. FWIW, everything mesa-related was on v26.1.4-1 on Arch at time of testing, and I tested on Proton Experimental bleeding-edge as well as Proton Hotfix.
proton hotfixx2 2026-07proton experimentalx1 2026-07RADV_DEBUG=fullsyncx1 2026-07RADV_DEBUG=fullsync`x1 2026-07RADV_DEBUG=nodcc,nohiz`x1 2026-05
Software information
Final Fantasy XIV 7.5 (Dawntrail), through
xivlauncher-rb. No other third party tools used.xivlauncher-rb: https://github.com/rankynbass/XIVLauncher.CoreUpstream
xivlauncher: https://github.com/goatcorp/XIVLauncher.CoreCorruption of the minimap, and only the minimap, while using any dxvk past 2.7.1 stable (WINE or Proton). Doesn't stick around, and only seems to crop up with either a lot or certain VFX are onscreen. Haven't nailed down any particular causes. The area in the screenshot and trace is Mistwake, using Duty Support. Corruption may or may not appear in content of other levels, but due to its tendencies to show up with a lot of onscreen VFX, combat in a party is your best bet.
System information
Apitrace file(s)
Log files
steam-default.log