Summary: | [ivb] mesa 19.0.0 breaks rendering in kitty | ||
---|---|---|---|
Product: | Mesa | Reporter: | Kovid Goyal <kovid> |
Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | danylo.piliaiev |
Version: | 19.0 | Keywords: | bisected, regression |
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
glxinfo output
api trace output of running kitty on mesa 19 |
Description
Kovid Goyal
2019-03-20 03:55:57 UTC
Created attachment 143737 [details]
api trace output of running kitty on mesa 19
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 <ian.d.romanick@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@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> :040000 040000 999198c729d569626942c3cbf2be1c8568188704 aa5820d52e85e7bcb6948cb7049a90e62d73f1be M src (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@test-HP-Z220-SFF-Workstation:~/mesa$ git bisect good > 4cd1a0be76883c2b13aae8c97972e8f1404d06f7 is the first bad commit > commit 4cd1a0be76883c2b13aae8c97972e8f1404d06f7 > Author: Ian Romanick <ian.d.romanick@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@intel.com> > Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> > > :040000 040000 999198c729d569626942c3cbf2be1c8568188704 > aa5820d52e85e7bcb6948cb7049a90e62d73f1be M src Then it should be fixed by : commit 6e184147ddce11e90c269a47af7d7395f5ed9c12 Author: Lionel Landwerlin <lionel.g.landwerlin@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@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@intel.com> that was the first I checked, Lionel. OpenGL ES profile version string: OpenGL ES 3.0 Mesa 19.1.0-devel (git-4fa61273a8) this latest master includes mentioned commit. But on IVB kitty.trace (from the https://bugs.freedesktop.org/show_bug.cgi?id=109759) and apitrace from current issue issue is visible and reproducable also I re-checked HSW and SNB - they work fine with provided commit. Issue is only on IVB (In reply to Denis from comment #5) > also I re-checked HSW and SNB - they work fine with provided commit. Issue > is only on IVB Thanks Denis. That's odd, I can't really see what else is different for IVB... Did you see the issue with 18.3.5 as well? >Did you see the issue with 18.3.5 as well?
I bisected between 18.2.8 (my system version) and master.
Just built 18.3.5 and issue doesn't reproduce in it.
I can ask our devs to debug mesa on IVB. Or, if you have suggestions or ideas to try - I am happy to check/support you.
(In reply to Denis from comment #7) > >Did you see the issue with 18.3.5 as well? > > I bisected between 18.2.8 (my system version) and master. > Just built 18.3.5 and issue doesn't reproduce in it. > > I can ask our devs to debug mesa on IVB. Or, if you have suggestions or > ideas to try - I am happy to check/support you. Not a lot of ideas unfortunately. Usually I fallback to diff the debug traces or aub files. One last test that would be helpful is whether 6e184147ddce11e90c269a47af7d7395f5ed9c12 fixed the issue on IVB and it got broken again later. >6e184147ddce11e90c269a47af7d7395f5ed9c12 fixed the issue on IVB and it got broken again later.
Mesa on this commit also reproduces this issue on IVB
I made a possible fix: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/512 Should be fixed by (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/520): commit 04508f57d1d36587f3cc048f0f5dae0611f9330c Author: Danylo Piliaiev <danylo.piliaiev@globallogic.com> Date: Mon Mar 25 14:15:27 2019 +0200 intel/compiler: Do not reswizzle dst if instruction writes to flag register |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.