<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [ivb] mesa 19.0.0 breaks rendering in kitty"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=110201#c3">Comment # 3</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [ivb] mesa 19.0.0 breaks rendering in kitty"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=110201">bug 110201</a>
              from <span class="vcard"><a class="email" href="mailto:lionel.g.landwerlin@linux.intel.com" title="Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>"> <span class="fn">Lionel Landwerlin</span></a>
</span></b>
        <pre>(In reply to Denis from <a href="show_bug.cgi?id=110201#c2">comment #2</a>)
<span class="quote">> 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@test-HP-Z220-SFF-Workstation:~/mesa$ git bisect good
> 4cd1a0be76883c2b13aae8c97972e8f1404d06f7 is the first bad commit
> commit 4cd1a0be76883c2b13aae8c97972e8f1404d06f7
> Author: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a>>
> 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 <<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a>>
>     Reviewed-by: Lionel Landwerlin <<a href="mailto:lionel.g.landwerlin@intel.com">lionel.g.landwerlin@intel.com</a>>

> :040000 040000 999198c729d569626942c3cbf2be1c8568188704
> aa5820d52e85e7bcb6948cb7049a90e62d73f1be M src</span >

Then it should be fixed by : 

commit 6e184147ddce11e90c269a47af7d7395f5ed9c12
Author: Lionel Landwerlin <<a href="mailto:lionel.g.landwerlin@intel.com">lionel.g.landwerlin@intel.com</a>>
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 <<a href="mailto:lionel.g.landwerlin@intel.com">lionel.g.landwerlin@intel.com</a>>
    Fixes: 4cd1a0be76883c ("i965/vec4: Propagate conditional modifiers from
more compares to other compares")
    Bugzilla: <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - [BISECTED][REGRESSION][IVB, HSW] Font rendering problem in OpenGL"
   href="show_bug.cgi?id=109759">https://bugs.freedesktop.org/show_bug.cgi?id=109759</a>
    Reviewed-by: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a>></pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>