Created attachment 66058 [details] Corrupted desktop I just updated mesa, libdrm snd the xf86-video-radeon to the newest git versions and now my screen is massivly corrupted (see the attached image). As you see this corruption isn't everywhere. By writing this text it flashed (sometimes more corrupt, sometimes less, sometimes not at all). No information at dmesg nor Xorg.0.log available. Kernel in use: Unpatched 3.6-rc3 BTW: It's hard to write a bug report with a corrupted screen (will attach a screenshot, too, so you got something to laugh).
Created attachment 66059 [details] bugs.freedesktop.org with the corruption
Created attachment 66060 [details] radeontop I just noticed that the GPU usage is very high (radeontop), so high that the desktop gets unusable in the LOW power profile. It spins between 20 and 80%
> I just updated mesa, libdrm snd the xf86-video-radeon to the newest git > versions and now my screen is massivly corrupted (see the attached image). Can you isolate which update caused the problem? > No information at dmesg nor Xorg.0.log available. Please always attach them to bug reports anyway.
Created attachment 66062 [details] Xorg.0.log (In reply to comment #3) > Can you isolate which update caused the problem? I don't remember the version of mesa before and it's not in the emerge.log (gentoo). But I'll try my best to get it. If you have any ideas feel free to share them.
Created attachment 66063 [details] dmesg
Okay, found a good commit and am bisecting. :)
Created attachment 66074 [details] My .drirc The bad commit is e7c177ec9e37d0c406c3b0ef8f228159d7ee5d69 ( st/dri: use driver name for driconf section lookup ) which sounds a bit weird. So I'm uploading my .drirc
If I set "pp_jimenezmlaa_color" to "0" everything is fine.
Well, it's reduced to a minimum, not solved. Need some more testing.
with both, ""pp_jimenezmlaa_color" and "pp_jimenezmlaa" setted to 0 it seems to be fixed completely. But I don't think activated MLAA should cause this.
(In reply to comment #7) > Created attachment 66074 [details] > My .drirc > > The bad commit is e7c177ec9e37d0c406c3b0ef8f228159d7ee5d69 ( st/dri: use driver > name for driconf section lookup ) which sounds a bit weird. > So I'm uploading my .drirc That commit makes mesa use real driver name ("r600") when it selects the device section from drirc. Before that patch "dri" was used instead. As long as your drirc doesn't have "dri" section (there are "r600" and "dri2"), then I think it was not used at all, so defaults were used. And now the settings from the "r600" section were activated after that commit. Probably you tried to enable MLAA earlier, that's why it was turned on in your drirc (but not active before that patch). I'm not sure how the MLAA should work, but your screenshot looks really antialiased, so probably it works now. You might want to try removing/renaming '.drirc' to use default settings again, if you aren't sure how to restore correct settings manually. Also you might use 'driconf' utility that will create '.drirc' with default settings for you if it doesn't exist.
(In reply to comment #11) I fully understand what the commit did. But I don't think MLAA should make the screen look like this, else nobody should enable it, so it's useless. Don't you agree?
(In reply to comment #12) > (In reply to comment #11) > I fully understand what the commit did. But I don't think MLAA should make the > screen look like this, else nobody should enable it, so it's useless. Don't you > agree? I think it should be enabled for some graphical applications only (games etc), not for all applications by default. drirc allows to use different settings for specific apps based on the executable name.
MLAA seems to be doing exactly as under Windows. I saw the same thing with Catalyst on Windows 7 mostly in Messenger. See http://www.sevenforums.com/software/182520-msn-live-messenger-browser-problem.html, http://www.sevenforums.com/software/182520-msn-live-messenger-browser-problem.html and comments in http://www.sevenforums.com/graphic-cards/166423-text-looks-if-water-has-been-poured.html So, for some reason, MLAA doesn't behave as expected with some applications (2D content where it "shouldn't")
(In reply to comment #14) > MLAA seems to be doing exactly as under Windows. I saw the same thing with > Catalyst on Windows 7 mostly in Messenger. See > http://www.sevenforums.com/software/182520-msn-live-messenger-browser-problem.html, > http://www.sevenforums.com/software/182520-msn-live-messenger-browser-problem.html > and comments in > http://www.sevenforums.com/graphic-cards/166423-text-looks-if-water-has-been-poured.html > > So, for some reason, MLAA doesn't behave as expected with some applications (2D > content where it "shouldn't") When you turn on MLAA in your drirc, it applies to all 3D applications. If you are using a 3D compositor (compiz, gnome shell, kwin, etc.) as a window manager, it will also apply to X apps. If you want to enable MLAA you'll need to specify what apps you want it to apply to in your drirc.
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.