[Bug 109404] [ANV] The Witcher 3 shadows flickering

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Jan 29 00:37:37 UTC 2019


https://bugs.freedesktop.org/show_bug.cgi?id=109404

--- Comment #19 from Matt Turner <mattst88 at gmail.com> ---
(In reply to Danylo from comment #18)
> What have I found on Friday:
> 
> The NIR I have attached is not a problem - it's a correct one as Jason
> corrected me on IRC.
> 
> The issue seems to be even further down, in native code such comparison
> generated:
> 
> asr.le.f0.0(8)  null<1>D        -g0<0,1,0>W     15D             { align1 1Q
> };
> 
> ...
> 
> (+f0.0) if(8)   JIP: 128        UIP: 128                        { align1 1Q
> };
> 
> The 15th bit of that register means:
> 
>   0: Front Facing 
>   1: Back Facing
> 
> Then it is negated to have:
> 
>   0: Back Facing
>   ~0: Front Facing
> 
> Then the *signed* .le (less or equal) with zero, as I see it - this is the
> wrong part, ~0 < 0 when comparison is signed however the initial intention
> was to have "false" in this comparison when triangle is front facing.
> 
> Manually changing null<1>D to null<1>UD fixes the issue.
> 
> How such comparison is created?
> 
> brw_fs_cmod_propagation.cpp, in opt_cmod_propagation_local, line 323 -
> CONDITION_LE modifier is propagated when condition operates on two
> REGISTER_TYPE_UD while scan_inst (opcode: asr) has dst: REGISTER_TYPE_D and
> src: REGISTER_TYPE_W.
> 
> From my point of view it's not a correct thing to do, but I'm not sure what
> to do here.

I'm just (In reply to Danylo from comment #18)
> What have I found on Friday:
> 
> The NIR I have attached is not a problem - it's a correct one as Jason
> corrected me on IRC.
> 
> The issue seems to be even further down, in native code such comparison
> generated:
> 
> asr.le.f0.0(8)  null<1>D        -g0<0,1,0>W     15D             { align1 1Q
> };
> 
> ...
> 
> (+f0.0) if(8)   JIP: 128        UIP: 128                        { align1 1Q
> };
> 
> The 15th bit of that register means:
> 
>   0: Front Facing 
>   1: Back Facing
> 
> Then it is negated to have:
> 
>   0: Back Facing
>   ~0: Front Facing
> 
> Then the *signed* .le (less or equal) with zero, as I see it - this is the
> wrong part, ~0 < 0 when comparison is signed however the initial intention
> was to have "false" in this comparison when triangle is front facing.
> 
> Manually changing null<1>D to null<1>UD fixes the issue.
> 
> How such comparison is created?
> 
> brw_fs_cmod_propagation.cpp, in opt_cmod_propagation_local, line 323 -
> CONDITION_LE modifier is propagated when condition operates on two
> REGISTER_TYPE_UD while scan_inst (opcode: asr) has dst: REGISTER_TYPE_D and
> src: REGISTER_TYPE_W.
> 
> From my point of view it's not a correct thing to do, but I'm not sure what
> to do here.

Thank you very much for the analysis (and attaching the shader). I'll take a
closer look.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20190129/ad0469ac/attachment.html>


More information about the intel-3d-bugs mailing list