KDE is currently blamed for errors in external components: the graphic drivers. I am lately reading quite some crap (e.g. on it news today) that we KWin devs knew about problems in the drivers and shipped 4.5 nevertheless with changes enabled which trigger the driver bugs. That is of course not true.
First let’s have a look on the checks KWin performs in desktop effects:
- Desktop effects are only enabled if the driver is on a whitelist of known working drivers
- The capabilities of the driver are verified by an external helper application
- If KWin crashes while initializing the driver (you have to access OpenGL to know if OpenGL is supported), KWin will not try to enable desktop effects again
- If KWin crashes twice in a row (not during driver initialization), desktop effects get disabled to prevent further crashes
- Each effect verifies the required capabilities by testing against the supported OpenGL extensions. So for example the blur effect requires GLSL with fragment shaders and frambebuffer objects. Only if the driver supports these extensions the effect gets activated. If a driver does not support the extension it should not claim support for it. The extensions are the only reliable information we have from the graphics driver.
- We have a test in 4.5.0 (removed in 4.5.1 – reason given below) that ensures that framebuffer objects are working in case the driver claims incorrectly support for the extension
- We have a dynamic blacklist that disables effects which require an extension the driver claims incorrectly support for it
- KWin has a selfcheck to test if desktop effects work at all, if not they are disabled
- KWin has a runtime performance check. If the performance is bad, desktop effects are disabled on the fly
The most important fact in this list is, that KWin does not enable any functionality the driver does not claim support for it! Furthermore we have several runtime checks to ensure that our users have a smooth experience even if the drivers are claiming support for extensions they do not support. Many of these checks have been added in the 4.4 and 4.5 release cycle.
Now that I have explained all our checks we did to ensure a smooth user experience, I want to explain how it could happen that there are regressions in 4.5. In 4.5 we introduced two new features which require OpenGL Shaders: the blur effect and the lanczos filter. Both are not hard requirements. Blur effect can easily be turned off by disabling the effect and the lanczos filter is controlled by the general effect level settings which is also used for Plasma and Oxygen animations. Both new features check for the required extensions and get only activated iff the driver claims support for it. So everything should be fine, shouldn’t it?
Apparently not when it comes to the free graphics drivers (please note and remember: we do not see such problems with the proprietary NVIDIA driver!). We used to use indirect rendering for Intel drivers. In that case the driver still claims support for all the extensions which cannot work with indirect rendering, that is for example framebuffer object and shaders (NVIDIA does not support such extensions if direct rendering is not enabled). If we ask the driver if it is supported it says: "yes sure, everything is fine", till you try to use it. This caused serious problems with the blur effect. The effect checks at startup what is supported, sees that everything is supported and tells Plasma that blur is available. Plasma uses therefore the blur optimized theme and then blur just does not work. We do not see the problem on initial startup or creation of the resources, such as compiling the shader, we see it only during the painting pass. This results in completely transparent and impossible to read windows.
Of course this is unacceptable. Disabling the blur effect by default would not have been an option as users would have enabled it and have run into this driver issue. So we had to check it. I added a test to try to get a framebuffer object during initialization. If it fails KWin does not enable the blur effect. Fixed the issue for all Intel users. But this caused other problems, so for some drivers when using a "strange" resolution (e.g. multi screen) compositing cannot be enabled at all. We still do not know what is happening there and cannot debug due to missing hardware. This check had been removed in 4.5.1 again as it was causing problems.
We could drop the check because we had found a better solution: the free drivers also support direct rendering and so we activated it. Of course only when our test application running outside of KWin verifies that direct rendering works. So everything is fine: blur works and no more problems.
Well not if we have the graphics stack in X11. We saw some new problems appearing out of nowhere. The Intel driver seems to be able to support shaders for hardware that is not programmable, that means: software emulation. That’s a rather stupid idea. You use shaders because you want to have the power of the GPU, not the slow general purpose CPU. A GPU (even a bad one) is magnitudes faster in image processing tasks than a CPU and is highly parallel. We also saw issues like windows being rendered upside-down (this issue had already been fixed in mesa git master before we were aware of this problem). This issue hit for example all users of radeon driver in OpenSUSE 11.3. A very nice problem seems to exist for Intel drivers. Given the bug reports we can only conclude that the driver is not able to handle more than one GL context at the same time or started shortly after each other.
When I see these problems I think: "it looks like we are the first one to actually use the drivers". And then I start to think about it and realize: yes we are. Compiz does not yet use GLSL (Compiz’s Blur effect is written in GPU assembler. KWin blur also has an assembler part which is a fallback in case the driver does not claim support for GLSL), so we are probably the first ones to use these driver capabilities in a real world application. Now why are we using something that new? Because it is quite old: this is OpenGL 2 we are speaking about, a standard specified in 2004! Btw. Microsoft made use of blur by default when they introduced Vista, that was in 2006. So we are talking about functionality specified since six years and used by default by our competition for four years. Oh and please note: the same hardware runs fine in Vista or Windows 7 – at least that’s what we can see from the bug reports.
As those new problems appeared I worked on another solution. Just in case that you didn’t know: I don’t have such hardware, I could not reproduce any of these issues. It’s also important to know that we need special combinations of hardware, driver version, mesa version, X server version, kernel version and distribution to have either failed or working setups. So there are easily thousands of possible combinations. Testing everything is just impossible. We introduced a blacklist to workaround the most prominent issues concerning blur and lanczos filter. Lanczos is more important as it cannot be disabled as easy as blur. The blacklist is implemented in a way so that it can easily be extended. I tried to cloud source the problem of finding all broken drivers. This did not work out for 4.5 and for 4.5.1 I just did not find the time to write a new kconfig update script. I hope to get an update ready for 4.5.2.
So far I discussed about the problems we saw and new about before 4.5.0. Given that we introduced several additional checks to ensure a good and smooth setup and all the work we put into ensuring a smooth user experience, I am rather disappointed being blamed for what we did. In my opinion we did everything that is possible. The only other option would have been to withdraw blur completely (as explained: disabling by default would not have solved the problem). This would be rather bad given that we have a large user base which wants blur and have a working driver!
An issue we were not aware of before the release (bug was opened during beta phase, but not confirmed before the release) are freezes when changing any KWin related settings. In fact it is not a freeze. You can still use Alt+Shift+F12 to disable compositing and enable it again and everything works fine. We still do not know what caused the problem, but it seems to be related to enabling direct rendering by default. Unfortunately I am unable to reproduce this problem on the only Intel based hardware I have access to. The only solution so far is to disable direct rendering in general again, but this would be a regression for all users where it is working fine (see above: it cannot be reproduced on each Intel hardware).
So we are in a situation where each of the possible ways to go, is wrong. And it is all caused by the drivers claiming support for functionality they do not support. If they would not do that, we would not have those problems. It is a rather disappointing situation. I can only repeat what is listed in the release note: use the latest drivers.
I hope this brings some light on the problems and shows that we did everything that is possible to work around the driver bugs. The issues have to be fixed in the drivers!
=-=-=-=-=
Powered by Blogilo
Damn! I was hitting the freeze bug VERY reliably with my N130 and F13 (with kde redhat repo) or F14 Alpha ๐ Why didn’t i hear that simple Alt + Shift + F12 is enough when all i was doing was killing kwin and plasma-desktop from another tty ๐
All in all KDE is progressing very nicely and i just love it. Thank You and other KDE developers for great work. Thanks!!
I think what’s important to understand is that the average user doesn’t understand what goes into developing a release. To them, it seemed as though it was working before, and it’s not working now. That’s all a non-programmer can understand.
I understand that you want the users with good graphics hardware drivers to enjoy the latest graphical developments, but Intel video cards account for a large portion of your user base, therefore I don’t think enabling those filters was a wise move.
My question is this, is there an Intel driver that does not suffer from this problem? If there isn’t, have you guys contacted them to work with them to try to get this resolved? From your post it sounds as though you enabled the filters “no matter what”, hoping that the popularity of KDE would cause Intel to cave in and fix it. If I’m wrong, please correct me.
The mistake I made in my blog was not emphasizing enough the actual problems I was experiencing. It was a lot worse for me than I portrayed in my article. It’s too late to go back and rewrite things to clarify the problems more. Anyway, since KDE 4.5, there are artifacts all over the place, bright white thumbnails and window previews, and performance a lot slower than before. For example, the animation of changing virtual desktops (the slide effect, or maybe it’s called box switching, something like that) misses several frames of animation several times in one switch. The entire desktop feels laggy to where it felt fast before with both 4.3 and 4.4. I’m sure as a developer you can realize the frustration a non-developer goes through when finding problems like these in a stable release, no matter what the cause.
Despite all that, tell me what I can do to help you, the developer get this fixed. Do you want me to scream at Intel? Do you need me to test some code for you? You have my email address and know where to contact me, I put my email on this post.
Agreed it is a large user base, but the user base where it is working is even larger. And for all the hardware where it should not work, the drivers should not claim support for it. For several issues (like e.g. the upside-down thumbnails with radeon) the fixes were already there. It is also very difficult to estimate how many users will be affected. Given the number of bug reports and comments before the release it was the right decision. Even after the release, I must say that it was the right decision. Please also remember that currently the users are running in general a KDE setup with outdated drivers. When distributions release with 4.5 there will be more recent drivers.
We added the blacklist just to disable the filters for drivers where it does not work. I am sorry that your driver is not yet listed. Feel free to send me the output of glxinfo, so that we can ensure that it will be blacklisted in 4.5.2 and as you read my blacklist blogpost, you should be able to blacklist yourself.
Given from feedback by users: yes. And as written in the blog post, I am not able to reproduce the freezing issue. All other issues can be fixed by disabling blur and the filter using the blacklist.
This is the lanczos filter and we added the blacklist for it. Again sorry that your driver is not yet blacklisted.
I am not aware of such problems. On the Intel hardware I have access to the animations are smoother than on my highend NVIDIA system.
No of course not. But you can also reach out to make users aware of the poor situation of graphics driver on X11 and that not KDE is to blame for them. This would really all be no issue, if the driver would not claim support for features it does not support. A year ago the driver did not claim support for those features, btw.
What I find strange is that Arch is a rolling release (as I’m sure you’re already aware) and should be using the latest everything. I find it strange to find out that this may not be the case. I will give you the appropriate glxinfo when I get home this evening. Also, I’ll give you the driver version if that will help you.
However, I still have to stick with my opinion that using these filters was not a good idea. I understand now the issue with the drivers and how the userbase without such cards is larger, but I still feel the same way. I don’t want to see this broken for such a large userbase, regardless of whether or not its the largest.
I’ll do what I can to assist in getting this fixed the right way. I would like to see no blacklist being required for things to work properly. I think that should be the ultimate goal.
Sometimes new drivers have regressions or require a newer kernel version than currently shipped with the distribution. For a fast moving stack like X a rolling release might not always be the best solution. There I think that stabilizing one set of components might be the better idea. But it seems difficult to say what is the best strategy.
So actually, what you’re saying is to upgrade the version of the Intel driver, in this case a kernel update would be necessary?
It is possible. Since mode setting moved to the kernel level we are seeing this more often that also the kernel version is important. That is a driver might only work correctly with one specific kernel. So breakage with both an older and a newer kernel is possible. As said the stack is highly volantile currently.
@Jeremy
Correct, many graphics drivers (especially accelerated ones) ship an X driver and a kernel driver that should be used together. The kernel driver provides access to the Direct Rendering Infrastructure, and access to the graphics cards hardware acceleration features. For a non-composited desktop, you can do without the kernel module (ATI’s fglrx X driver works without the kernel module loaded, but doesn’t provide hw acceleration in that case. If you have the fglrx kernel module loaded, it also provides hardware acceleration, and therefore compositing. The NVidia driver only works when the kernel module (nvidia.ko) is loaded. The same is true for the Free drivers, those are part of X.org (but can be released independently thanks to a modular structure that has been introduced after the fork from XFree86).
So for the driver part, the situation is pretty complicated, that shows in users’ setup problems. The best a normal mortal Linux user can do is to keep the system up to date, since the complexity of changing only parts of the components goes up pretty steeply. Updating X or your kernel are nothing for the faint-hearted of our userbase…
I think there’re 2 separate points to distinguish here:
1. technical upstream drivers are being developed and contain untested code (not-yet used in real applications). though from the technical POV one can understand the validity of Open GL 2 usage and other things
2. rolling these potentially untested stuff out on such a big scale is a dangerous thing to do. Which essentially leads to unhappy users, because there’re tons of configurations as you noted
I would propose (not just wanting to rent) following:
1. be way more careful with releasing new features (if you tested 1 configuration enable feature only in this 1 configuration, otherwise leave it disabled by default), mark features as experimental (explicitly in menus , warning users about it etc).
2. communicate more with driver developers. I’m not sure, but it seems for me that few gallium drivers, mesa itself, intel/ati drivers are being actively developed now and community is quite open, I bet they would love to work with *you* guys (kwin developers) to fix and debug issues
What you propose sounds fine in theory. Unfortunatly it does not work in practise. Let’s assume we know that feature A works with driver B and we ensure that only this combination is enabled. Now the distribution updates the driver to B.1 and everything breaks again. We already have a whitelist in kwin and it broke several times because it seems to be a developers fun game to change the rendering string ๐ This affects all drivers except NVIDIA – as long as I work on KWin we had to do adjustments for all drivers except NVIDIA.
if the driver update from B to B.1 break the features there’s definitely nothing to do… but I’m thinking there’re other issues as well, like feature not working with some driver at all, disabling the feature for the driver completely would help to avoid it
and clear communication with drivers developers community wouldn’t hurt (letting them know about kwin development)
though, there’s a good question to ask: does compize have similar issues? if not, what do they differently? could it help to avoid this issues in kwin as well?
I don’t imply you necessarily have to answer it, but it would be good to think about it, maybe talk to someone from their community
Well that with feature does not work at all, is what we did with the blacklist.
Compiz experiences similar issues, but the drivers are kind of optimized for Compiz as it is a long time around and uses more “legacy” OpenGL than kwin. We are in constant contact with Compiz developers and exchange experience.
I can feel the pain and disappointment in your blog entry. You want to create cool stuff for users and instead have to deal the bad code quality in the drivers and being blamed for subsequent issues.
Its similar to compiler bugs. Users don’t care if its an compiler bug or not and its the developers task to report this bugs by investing hours and hours to reduce the problem to 3 lines of code so you won’t be just ignored ^^
The difference is though that a compiler bug isn’t hardware specific in this x86_* dominated world. Plus GCC is a pretty mature piece of software.
But that’s how it is man. It looks to me like there is a need for a GLSL test suite that pins those bugs down and gives driver devs something to chew on.
Yeah I agree. Maybe there should be a lot more communication between the desktop effects programmers and driver programmers. maybe before implementing a feature in the Kwin or other composting widow manager a testcase for Piglit test suit for Mesa should be written and comminucated to Mesa developers community that KDE would like to use this effect in the next version and so ask if it driver developers could keep an eye on this testcase.
Yes, I think this would be the best way to handle this
Even without the prior advice, just having the troublesome code in a testcase would be a huge win. Assuming this isn’t happening, is it too difficult to write these testcases? Is it possible to record the OpenGL events to create test cases automatically (notice the crash and walk backward to some point of consistency)?
I plan to extract the complete rendering pipeline into an own module and submit is as a Piglit testcase. Though I do not know how long this will take and if it is possible at all. In any case such a change should make it possible to run a test suite for KDE users.
BTW, where is your Flattr button? I’d like to flattr this ๐
I do not like the idea of a company getting 10 % of what users are willing to donate. I think those 10 % can be used better, by e.g. donating to the KDE e.V. ๐
OK! KDE donation: done.
I have this feeling that driver developers don’t even use the software that excercises as many parts of the drivers as possible. What I was also thinking is that Xorg/Mesa 3D driver developers and KDE developers should one they organize a meeting (could maybe even be on IRC) and test the hell out of the graphics stack. BTW did any KDE KWin/Plasma developer ever been at X Developer’s Summit? I think it would really be great to get together and sit down and work out the problems in a BoF like session. XDS2010 is in about two weeks . http://www.x.org/wiki/Events/XDS2010
@Jeremy
I understand it is sometimes really frustrating if some very nice feature isn’t working for someone and it is easiest to start blaming the wrong one at this, even if one doesn’t want to. So I think that what would help the most is to actually focus on the real place or source of the problem and so educate readers of blogs and articles so that they become aware where the problem really is and not just where it apparently is. Only when people know where the real problem is the pressure can be applied into the right direction so that this gets fixed and everyone benefits.
The interaction with driver developers could be improved, yes. For me personal it would not make much sense to go to a X Developer Summit given that I do not have a notebook which can run free drivers. So I would not even be able to pinpoint the issues.
Perhaps attending an XDS doesn’t make sense but there always the X.Org mailing lists to raise issues. I’ve read the reaction of the drm maintainer Dave Airlie and basically he says that, for instance, gnome shell developers talk to driver devs before implementing a feature or that they open bug reports. He also said that bug reports they have against kwin come from individual not from you guys (kwin devs) and Torsten Marek says you only care about proprietary drivers, not for open source ones.
Obviously you’re pissed because you (kwin devs) are being blamed for bugs in drivers and X.Org devs are pissed at you guys because of your lack of communication.
Now I didn’t write this so you’d go scream at those X.Org devs but to urge you to talk to them just as you talk to compiz devs or qt devs. Try to get some of them into using KDE (I think most of them use GNOME). Also don’t give up on croud sourcing. I think it didn’t work for KDE 4.5.0 because it was a little late. Try to make a call for testing specifically for kwin once KDE 4.6 beta 1 is released and if possible put it on the dot (just like pim devs did for kontact 2.0). If you can’t ask Lubos or another kwin dev to do this. Finally I think it’s something worth raising in the kwin mailing lists
Hey,
thank you for this explanation and all your hard work! ๐ Wouldn’t it be a possibility to always use GPU assembler for the Blur effect just as Compiz does?
Do you have a contact at Intel to work on these bugs? I think the KWin project can profit from a good relationship with graphic driver developers.
How about asking for donations for buying testing hardware? I would donate 20 Euros for this.
SteBo
If you volunteer to maintain the assembler code ๐ I do not understand it and GLSL is one of the most pleasant languages I know of
The hardware is not the only problem. What it needs are enough users of each system to iron out such problems before the release.
I blacklisted my Driver for the Blur effect. Now everything works as it should. Before this desktop effects were so broken, I turned them off. The Driver string is:
Intel=965GM GEM 20100330 DEVELOPMENT:-:7.9-devel
Thanks for the driver string, but we do not blacklist DEVELOPMENT drivers. We think that users know what they do if they use development drivers and that they want to help the developers. Therefore blacklisting a development driver would be bad ๐
I feel for you! And I totally agree, drivers should only expose extensions they support. The devs of those drivers should be ashamed of themselfs and just go fix there code, with backports for earlier versions as well.
I wonder when fbsd will switch to the 4.5 series ๐
I’d like to thank you and the team behind kwin: thanks to your work I have a beautiful desktop and blur is really looking great here.
My laptop is working perfectly (I always buy nvidia after having tried amd cards on linux and window :p) and I’m sad that your great work is getting criticized by angry people.
Hardwares and drivers would really need a “standard”.. But it’s probably something unthinkable at the moment.
Thanks again for this great release ๐
Martin, a big “thank you” from me as well. You are doing tremendous work and I know many users why highly appreciate it. In fact, you are doing the whole GNU/Linux and X environment a big favor by pushing these features. These are exciting times for Linux graphics. New free drivers, new technology and the slow take-up of OpenGL and its cousins.
Keep it up!
Hello,
Thanks for the clarification. I have been bitten by the bug on two of my computers running intel and radeon drivers. On my nvidia computers running the binary blob this problem does not appear (though the present windows effect is much slower and the performance on a NVS135M is abysmal but this is nothing new).
I was wondering whether kwin developers could provide a small script that would provide a report on what the drivers pretend to support and what actually works. It could be semi-automated, for instance presenting and effect and a screenshot showing how it should look like. I have not the abilities to make such a thing but perhaps that could give a more systematic views to kwin developers of what works and what doesn’t for each kernel/driver version?
Anyway, thanks for your work!
I love your work and there is nothing to blame you.
i think the communication with xorg should be improved. perhaps invite some to the next kwin meeting (is there one?), make a xorg, compiz, kwin joint meeting or something like that. There must be a place where all important people meet at the same place.
I totally agree: the only solution instead of blaming each other is a tighter connection between upstream (driver devs), downstream (KDE devs) and distributors (distro packagers).
So is there a driver/ card combo which supports dual head and will allow Kwin to work as advertised ?
I currently have a nVidia Corporation G73 [GeForce 7600 GT] (rev a1). Even with the proprietary driver and blur / every other effect turned off i can still see the windows redraw when switching virtual desktops. Amarok is another good example, when you restore it from the tray you can see it being redrawn. Likewise resizing windows is also not smooth.
I love KDE and Kwin, just tell me what to buy and i’ll gladly ditch my existing setup for something thats speedy.
Slow resizing and slow first draw in NVIDIA is a completely different issue. Unfortunately I am not able to recommend anything – all drivers have problems and it depends on the user’s need what is the least problematic setup.
There’s an option (on the “Advanced” Tab) to save window previews always.
Although it says that it “fixex minimzation” minimizing and maximazong windows is a lot smoother on every tested system. So I don’t know what this warning is about…
This feature might cause some windows showing up as unminimized in the tasks applet. It causes video players to continue playing when minimized and stuff like that. That’s what the warning is about.
To be fair, I don’t have anything either to blame you.
Here the blur effect runs slow, but that’s because it’s unoptimized. Windows Vista blur also ran slow. My PC is happy with the rest of effects, and I run SC 4.5.1.
However, there are two things that actively workaround bugs I’m doing to improve my performance. One of them is to use the fork BeShadowed, instead of the Shadow plugin. The other one is to drop Oxygen, replacing it with Bespin (not only it goes faster, it does more eyecandy (thank you, Thomas ;)).
I trust you, so KWin 4.6 will be faster. Please, see what you can do with the Shadow effect, and, overall, what can you do about all effects. specially the ones that are required with Oxygen (namely the effect to darken inactive windows).
This driver situation is very frustrating. IMHO there is just too much change in the driver/X/kernel department, too much unfinished untested software is pushed onto end users. For such basic software this is just not acceptable. I mean the situation should be, that a system gets better over time. But this is not the case for the Linux graphics stack. It’s just in a constant state of brokenness. If one issue is fixed, you can be sure the next release has a different issue driving you mad. I’m using the free radeon driver on too older ATI cards in combination with compositing for some years now. I can’t see real improvements. Just recently I installed Ubuntu Lucid (LTS!!), I do a first reboot, radeon driver oopses, kernel freezes … great!
KWin really does a good job in trying cure the situation as good as it can, but it’s actually the wrong end to start fixing things.
Regarding your thoughts about feature A working with driver B, and then the distribution updates to driver B.1 and feature A breaks, but the blacklist still doesn’t veto driver B and the user gets the short end…
What about something where KWin periodically downloads a blacklist from a KDE server with updated information? That way even if your KWin stays old and your driver gets updated, KWin could get a fresh blacklist backported.
To go with this, a button in Desktop Effects settings like “Report display issues”, in which you have some checkboxes (and a comment field) where you can specify what’s not working well. Then it gathers up general info about xserver, kernel, driver version and glxinfo output, bundles it up and submits it someplace for your perusal. If it becomes statistically obvious that something in driver B.1 breaks feature A completely, or perhaps just when paired with X version C, then you can add that to the global backlist and have older KWins all over the world fetch and backport it.
I’m not sure if bko would be a good place to submit it to – perhaps it would get swamped? I was imagining something anonymous, like Microsoft’s report-a-crash feature.
For me 4.5 was just a big regression, because opengl stopped working after upgrading from 4.4.x to 4.5. I know that X/fglrx are not to blame because same works on 4.4 and completely doesn’t work on 4.5. So sometimes the problems are still inside kwin and not in 3rd party components.
Sorry, but the conclusion is just wrong. I understand that the user things so, that if it breaks it has to be in the app, but it is not the case here.
So… if we want our problems fixed we should send you hardware?
I agree with a couple of things people have said in response
1. Don’t enable new features by default in the first release (please). Does it hurt anyone to have them off by default for a whole release? users will find and try, and this will increase testing.
2. Moar communication!!! I really don’t care why whoever isn’t isn’t.
(as a statement I can program some small things but not hardware/graphics)
do you guys do automated testing? after seeing how CPAN works I often wonder why there aren’t more foss setups like it doing all kinds of regression testing.
3. don’t point fingers, I don’t care about that either. It’s your fault, it’s there fault, I know it’s not my fault… why? I’m not involved in writing this software. You and them get all the credit, even if that credit happens to be negative.
Seriously though, who do I send hardware to? How do I get this problem fixed and future proofed, so I don’t have to fear the next release of KDE?
Chin up! remember your biggest haters are probably your biggest fans ๐ if we didn’t love KDE we wouldn’t be bitchin’ because we wouldn’t be using it.
no, please don’t send me hardware as that is no solution.
to 1.: so we would have had the same problem have a year later, because nobody used the feature? And just to remember: most problems are not caused by the new effects and I am pretty sure that we would have seen exactly the same regressions in KWin if we would not have touched the source code at all
to 3.: I don’t point fingers, I explain the situation. If that involves showing that the problem are regressions in the driver, than that is the case.
How about following Linux kernel policy i.e. no new feature with default ‘on’ for at least one stable release?
You still need to encourage to test and report the success or bugs, but stability should be better..
This might work for the kernel, but I doubt that this would work for us
Any specific reason?
Given the number of blog I saw who complained about KDE’s slowness, if you don’t fix your release policy expect to become labelled ‘unstable software(*)’, and those tags sticks a loooonnnng time!
*: yes, this is the drivers fault, no it doesn’t matter!
If desktop foo is more stable than KDE because it doesn’t use drivers the same way, then KDE will look bad.
Yeah and that’s why I wrote the blog post. I wanted to explain why these things happened and that we tried everything reasonable so that we are not hit by the broken drivers.
I also think it would be a good idea to make kde-4.6 a stabilization release. Or maybe a major every 6 month is simple more than kde and its developers can handle.
Any improvement is welcome, I have the feeling since kde-4.2 there wasn’t a lot overall quality improvements. 4.x.0 releases are as bad as always, and no, I don’t have desktop effects turned on ๐
Yes, I saw your explanation and I’m not convinced, see my point before about kernel developers being more cautious than KDE is about new features..
It’s painful to slow down the delivery of new features, but given the current state of drivers, as evidenced by the current complaints, you have the choice: either slow down your release policy of ‘features by default’ which can disturb drivers, or being criticized (rightfully IMHO) for poor stability..
Here is my GLX info so you can make sure my card driver is black listed in KDE 4.5.2 if I haven’t already given it to you:
OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile GEM 20100328 2010Q1
I am testing Kubuntu 10.10 right now, and I’m having all the same issues except for one.
You are not the first one having those troubles! We have been suffering similar problems in Stellarium when we started to use GLSL. After 2 releases with GLSL code enabled by default we had so many angry users that we had to use no GLSL by default… In our case we also suffered endless additional problems caused on Qt + OpenGL driver bugs (even on windows).
To me, the only good solution would be to develop a complete drivers conformance testing tool which test every detail of the OpenGL standard. This could be used:
– by driver developers to improve their driver quality
– by linux distributions to discard a driver if it’s too bad
– by developers like us under the form of a library to perform run-time compliance checks.
Fab
Isn’t this what Piglit testsuite for Mesa is?
http://people.freedesktop.org/~nh/piglit/
As I said before. I think if a problem is found in KWin/Stellarium/other it should be added as a testcase to piglit. Well it should probably be added eve before the problems start being found. When an apps decides to use some function the first thing should probably be to add the testcase here and see how drivers pass it and then communicate to Mesa developers about his.
@Martin: I have a spare HD3870 gfx I wouldn’t mind donating for “the cause” if you’re interested.
Thanks for the offer, but my main system is just in the state of being switched to an Ati graphics card.
Again the typical finger-pointing so common in the OSS space :/
Well, I had my problems with 4.5.0, but in 4.5.1 my desktop effects on a 4500HD seem to be disabled when kwin starts.
I liked some of the effects, and it’s sad I can’t use them any longer, but well, I bought the notebook with the intel 4500hd card when I already knew about the bad state the intel drivers are in at the moment, so nobody else to blame but me :-).
Thanks for explaining the backgrounds on this, I enjoyed reading it. And I still hope for Intel to publish proper drivers :-).
Torsten Marek said on phoronix about kwin and its glsl problem: “To maintain the highest level of compatibility, I would go GL1.5, using the CG Toolkit to compile my GLSL shaders to ARB assembly.”
Does it makes sense to you? Is it a solution to the blur effect and the lanczos filter?
no, because lanczos is failing in fbo – if the shaders work we do not even know. Compiling with the Cg tool does not sound like a solution as it generates nvidia assembler
Please first read what Cg toolkit is. It can even convert GLSL shaders to HLSL and vice versa. It supports tons shader profiles, including ARB vp/fp.
I am not Torsten Marek.
Kwin is working fine here with nvidia 8400GS and latest 256 drivers installed via ppa for x in Kubuntu LTS 10.04, only Blur effect needs to be turned off to prevent CPU spikes.
So your post was picked up by a different news site, and some open-source driver devs are commenting extensively there.
Asides from giving their reasons on advertising not-fully-implemented GL versions, comments have included proposals similar to Tsiolkovsky’s and an expressed interest in contacting KWin developers. Martin, have you heard anything as of yet?
About a year ago, couple of my systems had Intel Graphics and I was experiencing severe performance issues. I replaced one of them with an old nVidia card and it made a huge day & night difference. Even an old clunker was running very fast.
Since then, I replaced all Intel graphics and never had any issues again. The last system I purchased nine months ago, I made sure it comes with nVidia graphics. Again, I never had any issues with it.
Intel is known to be a friendly big supporter of Linux, yet this graphics driver issue has been going on for a while now. Does anyone know why the heck they don’t bother to resolve it?
It seems to me that Intel intentionally doesn’t want to resolve the issue and in collaboration with Microsoft to sabotage Linux.
As MaikB said, it sounds like the best way forward is to develop a test suite that driver developers can test against. If it’s easy for application developers to contribute to such a test suite, they can add all the “real world” problems they hit to that test suite, and the test suite will gradually get better coverage, and drivers will become more reliable.
Keep up the good work, Martin!
Maybe slightly off-topic.
I suspect I’m running into KDE/X problems. A single application, all KDE applications (not firefox!) or the whole desktop can freeze. I can often still ssh into the box. Any pointers on how to track things down to create useful bug reports? I can’t see anything untoward in the syslog or Xorg log and GDB refuses to attach to the frozen applications (freezes itself). Memory doesn’t seem in short supply. On one occasion Xorg CPU usage was 100%. Intel drivers. KDE 4.4.5 (debian testing, Intel drivers from unstable).
Well, you should know that all these drivers are open source. That gives you immense powers: you can fix bugs all across the board. So don’t complain, just do! Don’t build work-arounds into software where they don’t belong. If some OpenGL call doesn’t work, then instead of working around the issue go and fix the call. That’s one of the key features of open source: we don’t have to work around, we can fix the real problems. So, stop complaining and just go and fix!
Seriously I cannot fix driver bugs in hardware I do not own. And we still have to workaround them as we cannot wait two years till the slowest distro picked up the drivers
I’m also suffering bad kwin performance with free radeon driver and my HD4730 card (R770). I’m not sure whether it is kwin’s fault or driver’s one, but the fact is that compiz runs much smoother than kwin. I’ve already fixed the problem with windows resizing (backfill issue), but still – having about 700-800 fps in glxgears with 1680×1050 resolution gives me quite laggy kwin. Maybe I just need to wait until mesa and readeon get mature and faster, and this seems to be the only promising case, because fglrx is a total crap (effects are even slower with it). But still, if it is possible to change smth in kwin to get it faster with radeon, I would be happy!
This forum post also suggests that the source of these problems is failed communication, thus a social problem:
http://www.phoronix.com/forums/showpost.php?p=145873&postcount=25
Yeah like discussing the fact of failed communication on the Phoronix forum instead of just contacting me? I totally agree.
Whoever finds sarcasm in this comment may keep it.
There should never be regressions. Compositing used to work fine on my machine and I got used to it. Now it doesn’t work anymore and help is not in sight, because KDE will just blame the X developers although the KDE devs never work with the X devs (like report bugs) like the Gnome people do.
Bottom line: *censored*
Finger pointing is a fun game. Unfurtonately just complaining that I do not report bugs does not help if you do not know the reasons for it.
OK, so why didn’t KDE test with different cards BEFORE releasing? And why didn’t the X devs get any bug reports?
oh right, because I have hundreds of graphics cards with all the different combinations of kernels and mesa versions. I just had one system and it’s a notebook with NVIDIA. So rather difficult to test the Ati driver for example. I thought that this is obvious.
Actually, I haven’t yet found someone who can use the effects with an intel card, while it worked fine under 4.4.x with the same kernel + x.org goodies. I’ve tried updating to newer kernels, newer x.org items, and still no luck.
If KDE is going to make changes that affect so many people, is it really out of line to seek testing on more than a single piece of hardware, which apparently is all you have?
I think these negative posts and your extremely feisty comments are not productive at all; your apparent need to defend yourself indicates that perhaps the big push in 4.5 wasn’t the best choice. In the end, as a user, I couldn’t care less about how right the KWIN guys are about the issue being in drivers, or mesa, or the x-server itself; when I update to KDE 4.5, my laptop shouldn’t lose functionality.
More testers are always welcome. We have a development release cycle and try to find as many problems as possible. Appearantly that has not been enough for 4.5 and I called for help via this blog. If we do not find the issues before the release there is hardly anything we can do about it.
Btw I only reply non productive, to non productive posts.
Perhaps you could attract more testers by doing a KWin bug day from time to time. A tester database with
– Tester name
– Tester contact information
– Available graphics hardware
would perhaps also make sense. This could just be a wiki page. In this wiki page the testers could also add which KWin version (e.g. KWin 4.6 Beta 1) they last tested and which problems they encountered (with links to existing/newly filed bugs on bugs.kde.org).
If you do not have all the graphics hardware that should be supported by KWin, maybe the KDE community can help. ๐
Is there an automated test suite that can be used to flush out new problems like these on various hardware platforms?
Tangentially, if the external-to-kwin testing program had an option to report back to KDE:
smolt UUID, if existing
driver versions
feature-set state
test
result
I’d turn it on for my machines. Get 10,000 people to do the same and you might have a decent up-to-date database of hardware compatibility on an ongoing basis.
{Since I can’t reply to the child of this post -}
@andrew: Leaving old i8** chips completely out if it, why should KWin hold itself back to the level open drivers _currently_ support at all? I’d love for all FOSS to work on my hardware with current drivers today, but software shouldn’t have to be held back. Or (as Martin has decided to) if exceptions are to be made for core desktop software, why should the ‘hordes’ of Kwin developers have to manually determine/confirm the support levels themselves for each and every driver?
I use nouveau on an NV43, and I am thankful to its developers that it can support as much KWin compositing as it currently can. None of the nouveau devs has ever told me to blame KWin when their rapidly-developing driver can’t support an effect yet. I may be drawing the wrong conclusion from this, but they seem to test nouveau and the graphics stack against KWin – not the other way around.
FOSS graphics devs get served a lot of unwarranted (*&%$, even when it’s not their software’s fault. So I’m surprised that a couple are defensively offering something far removed from empathy right now.
So, in other words, anyone not using an nvidia GPU should know that from this point forward, KDE Desktop Effects may just stop working for them at any time.
Good to know.
No, it’s also working fine with fglrx ๐ It’s just an oversimplification. You can always turn off all additional features and have just desktop effects.
Perhaps it is now, but during the 4.4.* series, with fglrx, I lost the ability to enable desktop effects through the control panel. The option was completely grayed out. I had to manually edit my kwinrc file to get them to enable.
Adam
Hello again Martin,
I wanted to update you that I’m having other problems with desktop effects in KDE 4.5.1. When I blacklisted the blur and lanczos filters, it does make things better, but I’m still seeing corruption. Notably, when I am scrolling contents up and down, I’m seeing heavy artifacts. Please email me if you need more info.
These driver issues are nothing new and started happening way back in KDE4.0 with the proprietary nvidia drivers.
There are several closed bugs in redhat-bugzilla discussing this issue as well as many all out wars in the KDE-users mailing list between users and Fedora developer Kevin Koffler.
Its about time that this issue got addressed.
True, the NVIDIA driver caused problems back in 4.0. Nowadays they do not cause much problems any more (that’s at least for me visible in the bugtracker)
Someone may have already suggested this. I haven’t read all of the above. But wouldn’t it be possible to write an app that profiles a given users machine?
i.e. Leave all compositing effects off and add a button and a procedure to allow the end user to profile the capabilities of their machine? before anything can be switched on. i.e. run through a variety of tests and collect the data on what works and what doesn’t. Based on the fact that this is essentially “beta” code I would think the end users would be happy with that. You could even have that app report back the stats, driver versions etc etc and build a reliable database of data you could take back to the driver devs to aid in problem resolution at their end.
Unfortunately it’s things like this that just make open source look bad. I know for me it’s not a problem, I work around issues and can diagnose the problems.
But for the end users I set up with linux desktops I cringe every time they apply an update and it does something like this to their systems.
I’m not assigning any blame to anyone. Just want to point out that a desktop “freeze”, to a less capable user is a very scary event and one that unfortunately they will compare to their previous computing experiences…”this never happened when I was running Windows”..
I really hate hearing that but the reality is that we (the Linux community), need to be better than this.
I love KDE and FOSS and everything that it is. All I can ask is that in future, things can be handled better.
Hi Martin. I don’t know how to contact you. I just wanted to tell you that I’ve experienced problems with the “Langzos”-effect. I have a intel Q45 (DQ45CB) chipset and adding the line “Intel=Q45/Q43 GEM 20100328 2010Q1:-:7.8.2” (extracted from glxinfo) to the section [Blacklist][Langzos] of kwinrc did solve my problems. Effects are now nice and fast. Maybe you could add this type of chipset to the _list_of_evil_graphics_chipset_ too :).
Bernhard
Thanks for the explanation. At least I have now an idea, why KDE feels so slow on my Computer while other people claim it is running fast even on netbooks. It seems that I just have the wrong grafik chip (intel).
After reading your blog I can’t blame you or the kde team for this, but the fact remains that compiz+gnome is working fine with this chip.
So whoever is to blame fore it, kde isn’t an option for me in the next future ๐
I second SteBo idea. I will be great opportunity to help improving Kwin and Open Source graphic stack.
Perhaps it is now, but during the 4.4.* series, with driver intel, I lost the ability to enable desktop effects through the control panel. The option was completely grayed out. I had to manually edit my kwinrc file to get them to enable and after that all work normall.
Blur and Langzos I don’t use.
Distro: Fedora 14 RC1
Kernel: 2.6.35.6-46.fc14.x86_64
Xorg: X.Org X Server 1.9.0
Driver: intel
Card model: 965GM
lspci: Intel Corporation Mobile GM965/GL960
kwinrc part before edit:
[$Version]
update_info=kwin_blacklist.upd:Blacklist-4.5,kwin_focus2.upd:kwin_focus2,kwin.upd:kde3.0r1,kwin.upd:kde3.2Xinerama,kwin_focus1.upd:kwin_focus1,kwin3_plugin.upd:k
[Blacklist][Blur]
Advanced Micro Devices=DRI R600:-:7.8.1,DRI R600:-:7.8.2
Ati=Radeon HD 3650:-:3.3.9901
NVIDIA=GeForce 6150/PCI/SSE2:-:195
[Blacklist][Lanczos]
Advanced Micro Devices=DRI R600:-:7.8.1,DRI R600:-:7.8.2
Intel=GM45 Express Chipset GEM 20100328:-:7.8.2,GM45 Express Chipset GEM 20091221:-:7.7.1,965GM GEM 20100328 2010Q1:-:7.8.2,965GM GEM 20091221 2009Q4:-:7.7.1,Iro
[Compositing]
CheckIsSafe=true
OpenGLIsUnsafe=true
kwinrc part after edit:
[$Version]
update_info=kwin_blacklist.upd:Blacklist-4.5,kwin_focus2.upd:kwin_focus2,kwin.upd:kde3.0r1,kwin.upd:kde3.2Xinerama,kwin_focus1.upd:kwin_focus1,kwin3_plugin.upd:k
[Blacklist][Blur]
Advanced Micro Devices=DRI R600:-:7.8.1,DRI R600:-:7.8.2
Ati=Radeon HD 3650:-:3.3.9901
NVIDIA=GeForce 6150/PCI/SSE2:-:195
[Blacklist][Lanczos]
Advanced Micro Devices=DRI R600:-:7.8.1,DRI R600:-:7.8.2
[Compositing]
AnimationSpeed=3
Backend=OpenGL
CheckIsSafe=false
DisableChecks=false
Enabled=true
GLDirect=true
GLMode=TFP
GLTextureFilter=1
GLVSync=true
HiddenPreviews=5
OpenGLIsUnsafe=false
UnredirectFullscreen=true
XRenderSmoothScale=false
I don’t check all effects, but enabled on default set work normally
Vinni Pux