|Summary:||Desktop icons oversaturated with red after December 11 2016 update|
|Component:||Drivers/Gallium/radeonsi||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED WONTFIX||QA Contact:||Default DRI bug account <dri-devel>|
|Priority:||high||CC:||bugs.freedesktop, calexil, chewi, dharding, EoD, eugene.shatokhin, evangelos, falaca, freedesktop, mattst88, mexahotabop, mightyiampresence, mr.swaagger, nhaehnle, philwyett.rebellion, tstellar|
|i915 platform:||i915 features:|
Screenshot with red-saturated icons
glxinfo default output
LLVM bisect log
Debug logs for 3.9.0 vs 3.9.1-git-25e2616
Description lesserbrute 2016-12-14 09:03:19 UTC
Created attachment 128464 [details] Screenshot with red-saturated icons I'am using optimized mesa drivers from oibaf's ppa and everything work well before monday update. The current version is 13.1~git1612131930.9fe3f2~gd~x. I tried to switch to padoka ppa and got rid of that "red icon" bug, but got a bunch of another glitches instead.
Comment 1 Michel Dänzer 2016-12-14 09:09:06 UTC
(In reply to lesserbrute from comment #0) > I'am using optimized mesa drivers from oibaf's ppa and everything work well > before monday update. The current version is 13.1~git1612131930.9fe3f2~gd~x. What was the previous version you updated from? Please attach the corresponding Xorg log file and output of glxinfo.
Comment 2 Eero Tamminen 2016-12-14 12:41:01 UTC
Based on your screenshot, you're using MINT distribution. Which desktop / widget toolkit you're using? And which GPU / Mesa driver you're using? (We've been checking Mesa Git Intel driver with Ubuntu 16.04 / Unity weekly and have never seen that kind of effect, and I'm not seeing it with yesterday's Mesa & X Intel DDX git version.)
Comment 3 lesserbrute 2016-12-14 12:54:23 UTC
Created attachment 128467 [details] glxinfo default output
Comment 6 lesserbrute 2016-12-14 12:59:29 UTC
(In reply to Michel Dänzer from comment #1) > (In reply to lesserbrute from comment #0) > > I'am using optimized mesa drivers from oibaf's ppa and everything work well > > before monday update. The current version is 13.1~git1612131930.9fe3f2~gd~x. > > What was the previous version you updated from? > > Please attach the corresponding Xorg log file and output of glxinfo. The latest bugless version for sure was 13.1~git1612080730.26ba8c~gd~x as I see in my apt history at 2016-12-09.
Comment 7 lesserbrute 2016-12-14 13:04:58 UTC
Also I have another PC with same Linux Mint and same Mesa up to date. It has integrated Intel graphics and icons looks normal.
Comment 8 lesserbrute 2016-12-14 13:10:15 UTC
(In reply to Eero Tamminen from comment #2) > Based on your screenshot, you're using MINT distribution. Which desktop / > widget toolkit you're using? And which GPU / Mesa driver you're using? MATE 1.14.1. GPU Radeon HD7850 / 2GB
Comment 9 lesserbrute 2016-12-14 15:32:28 UTC
Xviewer 1.0.6 - displayed images are oversaturated with blue http://i.imgur.com/8D7WtKL.png Gimp - Toolbox and menus icons are red.
Comment 10 Michel Dänzer 2016-12-15 07:03:13 UTC
There were quite a lot of changes between those two Mesa commits. Any chance you can bisect upstream Mesa Git?
Comment 11 lesserbrute 2016-12-15 10:01:52 UTC
(In reply to Michel Dänzer from comment #10) > There were quite a lot of changes between those two Mesa commits. Any chance > you can bisect upstream Mesa Git? Sorry, I'am not familiar with it.
Comment 12 Furkan 2016-12-20 23:15:11 UTC
I'm experiencing a similar issue after updating to the same packages. I ran some tests last night, with Michel's suggestions on IRC. The problem goes away when I build Mesa against LLVM 3.8. So the bug was most likely introduced between with the LLVM update, going from 3.9.0 to 3.9.1rc3. Hopefully I'll get around to bisecting it to find the offending commit.
Comment 13 Furkan 2016-12-21 02:51:48 UTC
Does your problem disappear when you downgrade your LLVM packages to 3.9 from here: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers/+sourcepub/6850286/+listing-archive-extra If you run dpkg -l | grep 3.9.1, I think that should get you the list of packages that you'll need to download from that page.
Comment 14 Furkan 2016-12-21 06:58:36 UTC
I ran a bisect on the LLVM 3.9 branch, and found the bad commit: commit 25e2616626caafb896517e18cd8aa724fba2b200 Author: Tom Stellard <firstname.lastname@example.org> Date: Tue Nov 29 03:41:28 2016 +0000 Merging r280589: ------------------------------------------------------------------------ r280589 | nhaehnle | 2016-09-03 05:26:32 -0700 (Sat, 03 Sep 2016) | 19 lines AMDGPU: Fix an interaction between WQM and polygon stippling Summary: This fixes a rare bug in polygon stippling with non-monolithic pixel shaders. The underlying problem is as follows: the prolog part contains the polygon stippling sequence, i.e. a kill. The main part then enables WQM based on the _reduced_ exec mask, effectively undoing most of the polygon stippling. Since we cannot know whether polygon stippling will be used, the main part of a non-monolithic shader must always return to exact mode to fix this problem. Reviewers: arsenm, tstellarAMD, mareko Subscribers: arsenm, llvm-commits, kzhuravl Differential Revision: https://reviews.llvm.org/D23131 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_39@288105 91177308-0d34-0410-b5e6-96231b3b80d8
Comment 15 Furkan 2016-12-21 07:00:01 UTC
Created attachment 128600 [details] LLVM bisect log Attaching bisect log.
Comment 16 Michel Dänzer 2016-12-21 11:01:14 UTC
Nicolai, please take a look. Furkan, it might be helpful if you can attach the stderr output from Xephyr with R600_DEBUG=ps when performing the same reproduction steps with a bad and good commit.
Comment 17 Furkan 2016-12-21 22:23:41 UTC
Created attachment 128622 [details] Debug logs for 3.9.0 vs 3.9.1-git-25e2616 Sure, Michel. I didn't rebuild the last good commit. So I'm comparing 3.9.0 (from oibaf ppa) with the first bad commit from 3.9.1 (25e2616). I hope that's close enough? For each build, I've included both the stderr log using the R600_DEBUG envvar and a screenshot of what Xephyr looks like.
Comment 18 John Brooks 2016-12-24 00:25:34 UTC
I also have this issue (and reverting commit 25e2616626caafb896517e18cd8aa724fba2b200 fixes it). Let me know if you need some testing/info.
Comment 19 Laurent carlier 2016-12-28 21:25:59 UTC
*** Bug 99215 has been marked as a duplicate of this bug. ***
Comment 20 junkmailnotread 2016-12-31 10:58:25 UTC
I had the same problem with Gentoo Linux when upgrading from llvm-3.9.0 to llvm-3.9.1: fbpanel icons exhibited a red shift. Reverting the above mentioned commit against llvm-3.9.1 fixed the problem.
Comment 21 calexil 2017-01-09 23:11:41 UTC
Same problem using the stable mesa padoka ppa, as of the most recent build llvm-toolchain-3.9 1:3.9.1-1~gd~x Oibaf (2017-01-08) mesa 1:13.0.3-3~x~padoka0 Paulo Dias (2017-01-08) https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/pkppa
Comment 22 calexil 2017-01-20 20:28:04 UTC
any news on this?
Comment 23 Alec Ari 2017-01-20 20:31:07 UTC
Same problem here, and for many other users: https://bugs.gentoo.org/show_bug.cgi?id=603858 Reverting this patch fixes it: https://github.com/llvm-mirror/llvm/commit/c280d74837d8239fc6cf567576b766ca3f4844c5
Comment 24 calexil 2017-01-21 00:29:31 UTC
*** Bug 99310 has been marked as a duplicate of this bug. ***
Comment 25 Alexandr Zelinsky 2017-01-21 04:29:13 UTC
svn llvm also fix this problem
Comment 26 Michel Dänzer 2017-01-21 07:25:06 UTC
Nicolai, Tom, any ideas for a solution other than reverting this commit from the LLVM 3.9 branch?
Comment 27 Nicolai Hähnle 2017-01-23 14:24:50 UTC
I can reproduce this now. Setting R600_DEBUG=mono in the environment of the X server works around the problem. I'm still trying to understand the exact problem and why it wasn't caught by piglit testing.
Comment 28 Matt Whitlock 2017-01-23 14:27:55 UTC
(In reply to Nicolai Hähnle from comment #27) > R600_DEBUG=mono Does this workaround have any negative consequences (e.g., performance regressions), or is it suitable for use in a daily-driver environment?
Comment 29 Nicolai Hähnle 2017-01-23 14:44:39 UTC
It's almost certainly because we missed 01a133c760ebb8db1e204f76ba55c19558b1ce01 "AMDGPU: Do not clobber SCC in SIWholeQuadMode" when back-porting -- probably because that one is not straight-forward at all to back-port. The best course of action would indeed be to revert that commit; IIRC it fixes a bug in Kodi, but the impact of that is much less than widespread weird tints. The part that really sucks is that I don't think an LLVM 3.9.2 is planned. We need to keep an eye out on whether this causes a problem in any distribution default installation. FWIW, I haven't seen a problem in Ubuntu 16.10 even though it does have LLVM 3.9.1, probably because the default installation of Mesa is ancient.
Comment 30 Nicolai Hähnle 2017-01-23 14:45:52 UTC
Re Matt, comment #28, that setting can result in more time spent on shader compiles. I don't think those are an issue in typical X server loads.
Comment 31 Shahar Or 2017-01-23 15:03:16 UTC
I've been using Ubuntu 16.10 for several months without this issue. On upgrade to 17.04, I was affected by this issue. Here is the issue in Ubuntu's tracker: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.9/+bug/1656620
Comment 32 Nicolai Hähnle 2017-01-23 16:58:45 UTC
Corresponding LLVM bug: https://llvm.org/bugs/show_bug.cgi?id=31722
Comment 33 Michel Dänzer 2017-01-24 01:15:03 UTC
(In reply to Nicolai Hähnle from comment #29) > We need to keep an eye out on whether this causes a problem in any > distribution default installation. Looks like Debian 9 will have Mesa 13 using LLVM 3.9.1, so it would probably be affected.
Comment 34 Andre Heider 2017-02-07 08:27:41 UTC
debian already reverted said patch for it's release 3.9.1-4 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852616
Comment 35 Matt Turner 2017-02-07 09:00:25 UTC
As did Gentoo in 3.9.1-r1.
Comment 36 Timothy Arceri 2018-04-11 06:00:11 UTC
The upstream bug was closed as wont fix and seems most distros reverted the offending patch. Closing as wont fix.