[Bug 110201] [ivb] mesa 19.0.0 breaks rendering in kitty
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Wed Mar 20 12:37:43 UTC 2019
https://bugs.freedesktop.org/show_bug.cgi?id=110201
--- Comment #3 from Lionel Landwerlin <lionel.g.landwerlin at linux.intel.com> ---
(In reply to Denis from comment #2)
> hi, thanks for the report. I reproduced issue on my IVB machine in the app
> (and in your apitrace, thanks and for it).
> Below bisected result:
>
>
>
> test at test-HP-Z220-SFF-Workstation:~/mesa$ git bisect good
> 4cd1a0be76883c2b13aae8c97972e8f1404d06f7 is the first bad commit
> commit 4cd1a0be76883c2b13aae8c97972e8f1404d06f7
> Author: Ian Romanick <ian.d.romanick at intel.com>
> Date: Tue Jun 19 18:09:05 2018 -0700
>
> i965/vec4: Propagate conditional modifiers from more compares to other
> compares
>
> If there is a CMP.NZ that compares a single component (via a .zzzz
> swizzle, for example) with 0, it can propagate its conditional modifier
> back to a previous CMP that writes only that component. The specific
> case that I saw was:
>
> cmp.l.f0(8) g42<1>.xF g61<4>.xF (abs)g18<4>.zF
> ...
> cmp.nz.f0(8) null<1>D g42<4>.xD 0D
>
> In this case we can just delete the second CMP.
>
> No changes on Broadwell or Skylake because they do not use the vec4
> backend. Also no changes on GM45 or Iron Lake.
>
> Sandy Bridge, Ivy Bridge, and Haswell had similar results. (Sandy Bridge
> shown)
> total instructions in shared programs: 10856676 -> 10852569 (-0.04%)
> instructions in affected programs: 228322 -> 224215 (-1.80%)
> helped: 1331
> HURT: 0
> helped stats (abs) min: 1 max: 7 x̄: 3.09 x̃: 4
> helped stats (rel) min: 0.11% max: 6.67% x̄: 1.88% x̃: 1.83%
> 95% mean confidence interval for instructions value: -3.19 -2.99
> 95% mean confidence interval for instructions %-change: -1.93% -1.83%
> Instructions are helped.
>
> total cycles in shared programs: 154788865 -> 154732047 (-0.04%)
> cycles in affected programs: 2485892 -> 2429074 (-2.29%)
> helped: 1097
> HURT: 59
> helped stats (abs) min: 2 max: 168 x̄: 51.96 x̃: 64
> helped stats (rel) min: 0.12% max: 12.70% x̄: 3.44% x̃: 2.22%
> HURT stats (abs) min: 2 max: 16 x̄: 3.02 x̃: 2
> HURT stats (rel) min: 0.18% max: 0.83% x̄: 0.64% x̃: 0.71%
> 95% mean confidence interval for cycles value: -51.04 -47.26
> 95% mean confidence interval for cycles %-change: -3.40% -3.07%
> Cycles are helped.
>
> Signed-off-by: Ian Romanick <ian.d.romanick at intel.com>
> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
>
> :040000 040000 999198c729d569626942c3cbf2be1c8568188704
> aa5820d52e85e7bcb6948cb7049a90e62d73f1be M src
Then it should be fixed by :
commit 6e184147ddce11e90c269a47af7d7395f5ed9c12
Author: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
Date: Wed Feb 27 15:53:21 2019 +0000
intel/compiler: use correct swizzle for replacement
The optimization in 4cd1a0be76883c introduced a replacement of :
cmp(8).z.f0.0 vgrf11.y:D, vgrf10.xxxx:D, vgrf2.xyyy:D
...
cmp(8).nz.f0.0 null.x:D, vgrf11.yyyy:D, 0D
By :
cmp(8).z.f0.0 vgrf15.x:D, vgrf10.xxxx:D, vgrf2.yyyy:D
...
mov(8) vgrf11.y:D, vgrf15.yyyy:D
The first cmp instruction is storing in x while the second mov is
sourcing from y. We need to take into account where the replacement on
the scan_inst destination is going to store thing so that the
replacement mov can source things from the correct location.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
Fixes: 4cd1a0be76883c ("i965/vec4: Propagate conditional modifiers from
more compares to other compares")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109759
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
--
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/20190320/aca0de89/attachment.html>
More information about the intel-3d-bugs
mailing list