Summary: | Flickering artifacts in radeonsi driver with divergent texture reads. | ||
---|---|---|---|
Product: | Mesa | Reporter: | Matias N. Goldberg <dark_sylinc> |
Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | Default DRI bug account <dri-devel> |
Severity: | normal | ||
Priority: | medium | CC: | julien.isorce |
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Sample repro
Pixel Shader used to receive these shadows (already stripped down & with tint) Vertex Shader used to receive these shadows (already stripped down & with tint) IR Generated by LLVM 3.9.1 IR Generated by LLVM 4.0 ASM 4.0 ASM from 3.9.1 Mesa patch |
Description
Matias N. Goldberg
2017-02-12 15:34:55 UTC
Created attachment 129531 [details]
Pixel Shader used to receive these shadows (already stripped down & with tint)
Created attachment 129532 [details]
Vertex Shader used to receive these shadows (already stripped down & with tint)
Created attachment 129533 [details]
IR Generated by LLVM 3.9.1
Took me a while to find the IR out of all the noise.
You should consider adding a Mesa extension to give human-readable names to shaders. It would help everyone in debugging A LOT.
I don't mind having
glSetNameMESA( shaderId, "My Filename" );
and internally Mesa keeps a std::map<int, string> or similar.
Created attachment 129534 [details]
IR Generated by LLVM 4.0
Created attachment 129535 [details]
ASM 4.0
Those readfirstlane instructions are incredibly suspicious
Created attachment 129536 [details]
ASM from 3.9.1
Analyzing the ASM it's clear what's happening: the 3.9.1 version branches everything. The 4.0 version branches the calculations, then at the end uses readfirstlane (this is WRONG) and finally performs one sample. I think this is the issue described in https://reviews.llvm.org/D26348 Not idea when the fix is going to go through though. Thanks for the referral.
I commented there, and they replied back with a potential fix:
> I believe it is very easy to fix, no need to change LLVM: marking the texture operation as having unknown side-effect should be enough.
Any comments? (perhaps you already know this but the performance hit could be huge?)
I've built LLVM 5.0 from latest SVN. I've applied the patch from https://reviews.llvm.org/D26348 The issue still persists. I don't know if anything else was needed (e.g. changes to radeonsi to make use of the patch?). Created attachment 129675 [details] [review] Mesa patch Yes, you need this patch for Mesa as well. I'm going to pick up the LLVM patch again as well these days. I can confirm applying the patch you uploaded (plus LLVM's patch of course) fixes the problem. Thank you. Just pushed a workaround for this issue in Mesa. https://cgit.freedesktop.org/mesa/mesa/commit/?id=7751ed39e40e08e5aa0633d018c9f25ad17f9bb0 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.