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.
(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.
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.)
Created attachment 128467 [details] glxinfo default output
Created attachment 128468 [details] inxi log
Created attachment 128469 [details] xorg
(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.
Also I have another PC with same Linux Mint and same Mesa up to date. It has integrated Intel graphics and icons looks normal.
(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
Xviewer 1.0.6 - displayed images are oversaturated with blue http://i.imgur.com/8D7WtKL.png Gimp - Toolbox and menus icons are red.
There were quite a lot of changes between those two Mesa commits. Any chance you can bisect upstream Mesa Git?
(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.
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.
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.
I ran a bisect on the LLVM 3.9 branch, and found the bad commit: commit 25e2616626caafb896517e18cd8aa724fba2b200 Author: Tom Stellard <thomas.stellard@amd.com> 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
Created attachment 128600 [details] LLVM bisect log Attaching bisect log.
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.
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.
I also have this issue (and reverting commit 25e2616626caafb896517e18cd8aa724fba2b200 fixes it). Let me know if you need some testing/info.
*** Bug 99215 has been marked as a duplicate of this bug. ***
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.
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
any news on this?
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
*** Bug 99310 has been marked as a duplicate of this bug. ***
svn llvm also fix this problem
Nicolai, Tom, any ideas for a solution other than reverting this commit from the LLVM 3.9 branch?
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.
(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?
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.
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.
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
Corresponding LLVM bug: https://llvm.org/bugs/show_bug.cgi?id=31722
(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.
debian already reverted said patch for it's release 3.9.1-4 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852616
As did Gentoo in 3.9.1-r1.
The upstream bug was closed as wont fix and seems most distros reverted the offending patch. Closing as wont fix.
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.