wine-nine-standalone
wine-nine-standalone copied to clipboard
iXit
some alphatests show bright outline pixels in Mirror's Edge
It doesn't look that way with native D3D9 on Windows or with DXVK. It might be that WineD3D shows the same issue, can re-check that.
I once noticed this a year or two ago on Polaris and can still confirm with RX 5700 XT and recent mesa-git. Not related to MSAA.
Can you please give us an apitrace or at least a savegame so that we can reproduce this issue?
Sure, I'm going to post an apitrace soon. The issue is already visible in the beginning of the tutorial level when looking at the orange walking grids.
Native D3D9 captured on Windows: https://drive.google.com/file/d/1imZf0X9cmB3AOZxek2Vy0nRcZzhuE5pG/view?usp=sharing
With the trace taken on windows, it replays fine with my local mesa. Maybe it's some flags nine doesn't advertise correctly. When you replay locally do you see the issue ?
Btw for future traces: To find bugs, we have to run many many time the traces, thus it helps to set a low resolution (vsync on to cap framerate) such that it replays very fast.
I haven't actually replayed any of my apitraces so far. I just did so and realized how inconvenient the slow-motion speed is. Sorry about that!
Yes, I can see the slight corruption in the apitrace with Nine, whereas it's not there with DXVK.
Nine (it seems to be most prominent in shadowed areas, but it looks to me like if the alphatests also looked too aliased in bright areas):
DXVK RADV ACO:
I also reproduced with WineD3D and it looks like Gallium Nine. So I'd suspect the issue is in Mesa/RadeonSI/LLVM and not Gallium Nine.
Indeed I can reproduce this artifact. To investigate it, I would need a trace that can execute very fast please.
I think the game was already heavily throttled by apitrace CPU overhead. Would it help further if I capped the frame rate to e.g. 10fps or so for the capture process?
Here are two new traces (720p 10fps): One is a bit shorter and shows the alphatests from afar, while the other is a bit longer to show the corruption up close: https://drive.google.com/file/d/1ez76hBfCauss2Ah0obXQ412XFWH88Sot/view?usp=sharing
The issue starts occurring with high texture details, so perhaps it's something with normal/bump mapping (wild guess)?
21647774 is one of the calls of the long trace that draws the buggy stairs.
The shader features a texkill and it is apparent the buggy pattern happens on a grid of 2x2 superpixels when at least one pixel is not drawn. Thus it is yet another texkill/WQM radeonsi llvm bug.
Thanks for your analysis! So this would need to be fixed in LLVM? I could try llvm-git from unofficial mesa-git repository for Arch (as building it is too painful with my 6700k).
Edit: Ok, it's unchanged with lib32-llvm-libs-git 12.0.0_r374967.eb66bf0802f9-1. Waiting for RadeonSI ACO? :grin:
@aufkrawall Since you mentioned that this works correctly with DXVK + RADV/ACO, can I ask you to please try if it works or not with DXVK + RADV/LLVM? This would help identify if it really is an LLVM bug or not. You will need to use the RADV_DEBUG=llvm environment variable.
Yeah, I should have thought of that. Indeed then the issue is also there with DXVK + RADV:
Interesting. Thanks @aufkrawall for checking. This is either a bug in LLVM itself, or mesa's usage of LLVM.