Created attachment 69689 [details] Screen snapshot: fading rendering Having installed mesa 9. Compiz works @ ~5 FPS producing output as if one is drawing in aquarelle on a wet paper (pls see attachment). Wallpapers are rendered properly while all the windows are drawn this way. Meanwhile nothing unusual were found in logs. I installed it on Gentoo by unmasking my arch then update. It also required to add libGLU. I tried few pre-releases as well as 9.0 on both 3.4 and 3.6 kernels with the same result. I assume maybe some other changes are required I'm not aware of. Version of software are media-libs/mesa-9.0 x11-drivers/xf86-video-ati-6.14.6-r1 x11-libs/libdrm-2.4.40
Please attach dmesg, Xorg.log and the output from glxinfo
Did you turn on MLAA? If yes, turn it off. It can blur your desktop too.
Yes, Marek was right. Disabling MLAA made it work as expected. Mesa 9 with no MLAA (compared with 8.0.4 with MLAA enabled) shows about 15-20% performance boost but fonts look rougher though...
Created attachment 69758 [details] Glxinfo output
Created attachment 69759 [details] Xorg.0.log
Created attachment 69760 [details] dmesg output
I suspect you weren't getting MLAA under mesa 8.x since IIRC the way drirc options were handled by gallium drivers changed between 8.x and 9.x.
Just to make sure we understood each other correctly... MLAA worked for me in 8.0 and it seems to be a regression in 9.0. Is there something I can do about it?
(In reply to comment #8) > MLAA worked for me in 8.0 and it seems to be a regression in 9.0. Comment #7 explained that MLAA may not actually have been enabled with 8.0. (How) Did you verify that it was?
(In reply to comment #8) > Just to make sure we understood each other correctly... > MLAA worked for me in 8.0 and it seems to be a regression in 9.0. > Is there something I can do about it? I'm saying I don't think MLAA was actually enabled in 8.x due the changes in the way drirc options are handled in gallium drivers between 8.x and 9.x. The changes you see in 9.x are a result of MLAA being enabled when you switched whereas it was previously not enabled under 8.x. Here is the relevant commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=e7c177ec9e37d0c406c3b0ef8f228159d7ee5d69 Prior to that commit, the driver name in your drirc had to be "dri" to work with gallim drivers. After that commit, it now matches the actual driver name, e.g., "r600".
(In reply to comment #9) > MLAA may not actually have been enabled with 8.0. > (How) Did you verify that it was? I did not, but the first impression was the font rendering has changed a little bit, but I'm not 100% sure. Probably it did not. At least I can say "MLAA" never appeared in Xorg log, but I'm not sure if it had to... I may perform a dumb check if it is important: compile 8.0.4 back then switch MLAA on and off via driconf to see if there is any real difference... or you may suggest a smarter way...
(In reply to comment #11) > (In reply to comment #9) > > MLAA may not actually have been enabled with 8.0. > > (How) Did you verify that it was? > I did not, but the first impression was the font rendering has changed a > little bit, but I'm not 100% sure. Probably it did not. At least I can say > "MLAA" never appeared in Xorg log, but I'm not sure if it had to... I may > perform a dumb check if it is important: compile 8.0.4 back then switch MLAA > on and off via driconf to see if there is any real difference... or you may > suggest a smarter way... Try removing your drirc configuration. that should remove MLAA. Then try your drirc config again with 8.x and 9.x but change the driver name between "dri" and "r600". With "dri", you should get MLAA under mesa 8.x with "r600" you should get MLAA under 9.x.
You could attach your driconf. Then we could see if MLAA was enabled in mesa-8.0.4 or not. P.S: Your Evergreen card uses the r600g (gallium) driver and not radeon classic.
Created attachment 69769 [details] Current drirc configuration suitable for mesa 9.0 Until today both pp_jimenezmlaa and pp_jimenezmlaa_color were set to 8
(In reply to comment #14) > Created attachment 69769 [details] > Current drirc configuration suitable for mesa 9.0 > > Until today both pp_jimenezmlaa and pp_jimenezmlaa_color were set to 8 <device screen="0" driver="r600"> This would only work on mesa 9.x. You'll need: <device screen="0" driver="dri"> for mesa 8.x
(In reply to comment #13) > You could attach your driconf. > Then we could see if MLAA was enabled in mesa-8.0.4 or not. This discussion has shown me that I was naive enough to think that things would work being switched on and that it's not always true))) So if you guys are interested in getting more info, I'll do further experiments. In this case I'd like to know if there are any reliable means to make sure MLAA is really working or not (besides blur and 300x slowdown, of course. This was quite obvious) to give you a proper feedback. If you got enough, I'll experiment on my own to find out what is more suitable for me for the moment not involving you anymore - I got enough info. Now I got mesa 9 working more or less and you are aware that MLAA is not working properly in my case. Anyways, thank you for your help with the case as well as for you efforts in keeping improving Linux graphics. > P.S: Your Evergreen card uses the r600g (gallium) driver and not radeon > classic. I'm aware that classic drivers were removed in favor of Gallium. Thank you.
(In reply to comment #16) > Now I got mesa 9 working more or less and you are aware that MLAA is > not working properly in my case. I suspect that it works as intended though it's not what one might expect comparing to similar options in proprietary drivers. As far as I understand, expected usage of MLAA with Mesa is to enable it only for the applications where you want it (games etc) with either app-specific drirc settings or environment variables. If you enable MLAA in the global settings, it means "use MLAA for everything" (for all applications including compiz) and that's probably not what you want. So I don't think it's a bug, though perhaps it would be nice to make Mesa behave more like other drivers.
(In reply to comment #17) > I suspect that it works as intended though it's not what one might expect > comparing to similar options in proprietary drivers. I think you're completely right. In my case the issue was provoked by two things: first, the program I use (GTK driconf o.9.1) suggests MLAA to be set to 8 as default value (however, resets it to 0 by default), and second, that it did not actually work for me in mesa 8.0. So I was misled a little bit after I installed mesa 9... > As far as I understand, expected usage of MLAA with Mesa is to enable it > only for the applications where you want it (games etc) with either > app-specific drirc settings or environment variables. It is probably so. A **huge** problem for me is a common lack of documentation. I'm okay with English and not too lazy to read but I could hardly find what to read, though. I mean - relevant while not obsolete. Things usually work in default configuration, which may not be optimal for some cases, and if I want to do something about it - this is where troubles begin - for me and maybe for developers who have to answer my sometimes stupid questions. All this video stuff looks so complicated and chaotic for me due to lack of documentation... I even did not comprehend if mesa is commonly responsible only for 3D rendering how comes erroneously enabled MLAA blurs fonts, too. Fonts currently are rendered by DDX driver, aren't they? > So I don't think it's a bug, though perhaps it would be nice to make Mesa > behave more like other drivers. Or at least, make things documented somehow. Currently the tuning knobs are spread across three areas: drirc (which is created somehow, or not, often beyond the user control); environment variables (hardly documented), Xorg.conf. Oh yes, there is fourth: USE flags/.configure options. A little bit to complicated... Just the same, thank you guys for what you do.
(In reply to comment #18) > > As far as I understand, expected usage of MLAA with Mesa is to enable it > > only for the applications where you want it (games etc) with either > > app-specific drirc settings or environment variables. > It is probably so. A **huge** problem for me is a common lack of > documentation. I'm okay with English and not too lazy to read but I could > hardly find what to read, though. I mean - relevant while not obsolete. > Things usually work in default configuration, which may not be optimal for > some cases, and if I want to do something about it - this is where troubles > begin - for me and maybe for developers who have to answer my sometimes > stupid questions. All this video stuff looks so complicated and chaotic for > me due to lack of documentation... I even did not comprehend if mesa is > commonly responsible only for 3D rendering how comes erroneously enabled > MLAA blurs fonts, too. Fonts currently are rendered by DDX driver, aren't > they? MLAA affects all rendering that goes through OpenGL. While the text rendering for non-GL X apps may be rendered by the ddx using xrendr, the pixmaps end up going though OpenGL if you are using an OpenGL compositor (gnome shell/compiz/kwin/etc.). When the application window is composited to the front buffer by the OpenGL compositor, the MLAA is applied.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/425.
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.