[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