[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