KDE SC 4.6 Release Candidate 1 Makes It Out

[pingufunkybeat]

Hrm...

It seems that Dolphin does have problems with r600g (but not r600c!)

Every time I start it, the compositing gets disabled because everything slows down to a crawl. Closing Dolphin and restarting compositing makes it OK again...

EDIT : But only on one of my r700 cards, not on the other.

[mgraesslin]

On the one hand, the actual status of the graphics drivers was not really taken into account--something that transpired quite clearly from the developer blog posts. After the 4.5 backslash all that guy came up with was a lot of finger pointing.

To get some things right:
1. I have been writing the blog post, but not the code for blur nor for Lanczos. This code has been written on an Ati card with Mesa drivers. It was working on that hardware!
2. We have seen a hughe regression in driver quality. You could take the code from 4.0 run it on the hardware/driver combo current at that time and see it working. Now update the driver to what has been current on 4.5 and everything starts to fail. I have seen KWin running smoothly with blur enabled on an Intel hardware on Debian squeeze. If you try the same with more recent driver stack (e.g. Kubuntu 10.10) it starts to fail.
3. The code for blur/Lanczos was written before the feature freeze. Lanczos hit trunk on May 11th, blur on March 5th. Mesa 7.9 which is used in most distros in combination with 4.5 has been released on October 4th. That is half a year later than the time when we wrote the code. We can do lots but not develop against not yet developed drivers. Mesa 7.8.2 was released on June 17th which is way after our feature freeze, the previous releases were all development versions.
4. I have switched to an Ati system in order to also test and develop with Mesa. The driver fails that badly that I have to run fglrx. The graphics card is two years old!
5. After the 4.5 backslash with all the finger pointing I started reporting bug reports on the mesa bugtracker, but never got any reply. I will not waste my time again.

Blaiming that all I did is finger pointing is quite an insult. Please inform about the situation properly. I simply explained the situation and the situation is regression in the drivers. The pity is that the driver developers do not see any fault there and are not realizing that they are harming the free desktop graphics stack by claiming support for extensions which are not supported. I read comments here on Phoronix from the devs being proud about their software emulation of shaders. That might be a great idea for games but its the worst thing to happen for a compositing manager.

We are currently seeing again regressions with the gallium drivers. They now support NPOT by emulating them in shaders which causes serious performance regressions. Awesome completely breaks our existing checks whether the graphics card supports NPOT :-(

Btw I spent hundreds of hours improving the rendering stack in both 4.6 and 4.7 which makes uninformed comments like yours quite unbearable.

[pingufunkybeat]

Martin,

thanks for your work on KWin. I appreciate that.

Don't you think that some sort of an arrangement where the Mesa developers and KWin developers work with each other is preferable? Even if things were suboptimal in the past and there is a grudge or two, wouldn't it be better to sit together and decide how to deal with these things in the future?

Saying "I will not waste my time [reporting driver bugs] again" does not sound like we can look forward to better cooperation in the future. This is sad, because it might affect millions of KDE users, like it did last time.

After all, we are all in the same boat. Guys like Marek are also unpaid volunteers who put a lot of effort into these drivers, and they also get loads of crap on these forums. Just a thought.

[mgraesslin]

Don't you think that some sort of an arrangement where the Mesa developers and KWin developers work with each other is preferable? Even if things were suboptimal in the past and there is a grudge or two, wouldn't it be better to sit together and decide how to deal with these things in the future?.

Of course everything would be better than the current state. That's why I started reporting bugs, started following this forum, tried to use radeon, are using nouveau, went to UDS. Other devs submitted piglit tests, I am planning to add our complete rendering stack as piglit tests and so on and so on.

Saying "I will not waste my time [reporting driver bugs] again" does not sound like we can look forward to better cooperation in the future. This is sad, because it might affect millions of KDE users, like it did last time.

After all, we are all in the same boat. Guys like Marek are also unpaid volunteers who put a lot of effort into these drivers, and they also get loads of crap on these forums. Just a thought.

Very true, unfortunately my time as a volunteer is also very limited. If you made bad experience you will try to focus on other things to improve the situation.

I don't want to do finger pointing, but I must say that what I read in this forum quite bewildered me. Reading complaints about bad communication and nobody gets in touch with me or our development team. Developers read my blog posts and commented here...

I hope that there will be the chance to meet in real life and to discuss what is needed to keep compositors going. As it does not only affect the millions of KDE users, but also the millions of soon GNOME Shell and Unity users (Unity has higher hardware requirements than KWin 4.5).

[pingufunkybeat]

I don't want to do finger pointing, but I must say that what I read in this forum quite bewildered me.

Most of what I read here bewilders me on a daily basis, I wouldn't take the massive whining here as a representative sample of anything. People get a bad experience, and then register just to whine.

Still, I hope that the communication between the KDE devs and Mesa devs (and all other FLOSS devs for that matter) can improve. I'm sure that it's in the best interest of all sides involved.

[yotambien]

To get some things right:
1. I have been writing the blog post, but not the code for blur nor for Lanczos. This code has been written on an Ati card with Mesa drivers. It was working on that hardware!
2. We have seen a hughe regression in driver quality. You could take the code from 4.0 run it on the hardware/driver combo current at that time and see it working. Now update the driver to what has been current on 4.5 and everything starts to fail. I have seen KWin running smoothly with blur enabled on an Intel hardware on Debian squeeze. If you try the same with more recent driver stack (e.g. Kubuntu 10.10) it starts to fail.
3. The code for blur/Lanczos was written before the feature freeze. Lanczos hit trunk on May 11th, blur on March 5th. Mesa 7.9 which is used in most distros in combination with 4.5 has been released on October 4th. That is half a year later than the time when we wrote the code. We can do lots but not develop against not yet developed drivers. Mesa 7.8.2 was released on June 17th which is way after our feature freeze, the previous releases were all development versions.
4. I have switched to an Ati system in order to also test and develop with Mesa. The driver fails that badly that I have to run fglrx. The graphics card is two years old!
5. After the 4.5 backslash with all the finger pointing I started reporting bug reports on the mesa bugtracker, but never got any reply. I will not waste my time again.

Thanks for the reply. Let's see, are you saying that at some point in time everything worked perfectly and in a performant manner using certain combination of KWin and mesa drivers? Certainly that wasn't what I experienced. Granted, I tend to run stuff from upstream, but I also check what's on sid repositories and I don't remember having a really smooth KDE desktop with compositing on. My expectations are probably higher than most, though, for I won't activate compositing unless I don't notice any performance difference as compared with a plain, regular desktop.

You appear surprised about the existing lag between the OSS drivers and the proprietary ones ("The graphics card is two years old!"). I don't excuse anything and I'm as frustrated as every other Linux user when stuff like this doesn't work--my card is 7 years old, by the way. But this is precisely the kind of thing I was talking about when mentioning that the actual status of the graphics drivers was not really taken into account. Obviously, I can't give you any technical reasons about why the drivers do what they do: I still think it's your job to follow closely what's going on upstream since the result of your efforts will be conditioned by this. You mention that you can't develop against not yet developed drivers. That's not exactly right, since you always have the option of compiling the upstream sources. Now, I don't ask you to do so, and you know better than anybody else what's the best use of your time. However, is there a possibility that some of these problems would have been noticed by merely following more closely the drivers development?

Blaiming that all I did is finger pointing is quite an insult. Please inform about the situation properly[...]Btw I spent hundreds of hours improving the rendering stack in both 4.6 and 4.7 which makes uninformed comments like yours quite unbearable.

Sorry about that. But I think you gave my comment a wider meaning than I really intended. I didn't want to imply that since 4.5 you did absolutely nothing, but rather that the first answer the world knew from you after the criticism was finger pointing. And really, that's what it looked like. On top of that, bear in mind that you are dealing with a diletantte here, I'm as informed as any average joe who follows some Linux sites. Your contributions are appreciated, both in terms of code and comments.

Actually, if you feel like it, I would welcome an explanation about why Compiz works as opposed to KWin and whether you think KWin's design decisions and improved rendering work will allow for the same performance levels in the near future.

[mgraesslin]

You appear surprised about the existing lag between the OSS drivers and the proprietary ones ("The graphics card is two years old!").

That's not what I meant. The problem is that I do not have any GL on that card with the free drivers.

That's not exactly right, since you always have the option of compiling the upstream sources.

No and exactly that is not possible. For the development of 4.6 (June to October) the current development version was 7.9. But at the time distros will ship 4.6 (Spring 2011) it will be bundled with mesa 7.10 which is not in development during our development.

However, is there a possibility that some of these problems would have been noticed by merely following more closely the drivers development?

I would turn it around. Several problems would have been noticed if driver developers would follow downstream development more closely. Which is much more easier because distros provide daily build packages.

but rather that the first answer the world knew from you after the criticism was finger pointing.

you mean it was the first thing quoted on Phoronix? Sorry that's not my fault as there have been quite some blog posts on the situation already before. Just follow planetkde.

Actually, if you feel like it, I would welcome an explanation about why Compiz works as opposed to KWin and whether you think KWin's design decisions and improved rendering work will allow for the same performance levels in the near future.

I don't know exactly why Compiz performs better but we found some bugs in the rendering stack which will be fixed in 4.6. So I think that KWin will be on par from a performance point of view in 4.6 and I expect that 4.7 will be better than current Compiz (but I expect Compiz to also improve).

[rvdboom]

We are currently seeing again regressions with the gallium drivers. They now support NPOT by emulating them in shaders which causes serious performance regressions. Awesome completely breaks our existing checks whether the graphics card supports NPOT :-(

Hi, Martin.
First of all, I think everybody in the graphic stack right now aims a moving target, whether you, the graphic driver or the mesa driver and that's certainly not confortable for anyone. I wish people would stop complaining and either help or wait, as I don't think this endless bashing will help in any way.

I'm using Slackware and I've just tried the KDE 4.6RC1 packages provided by Alien Bob. This is on a laptop with a RS480 ATI chipset, and I use the latest git pull for libdrm, mesa and xf86-video-ati, AND the Gallium driver. With KDE 4.5.3, I just needed to disable the tests at the start and the Blur plug-in and OpenGL compositing worked fine. With 4.6RC1, OpenGL doesn't work at all, XRender does (and is actually quite smooth).
Is this the kind of regressions you saw? Do you have some idea what changed that made 4.5.3 work on this kind of setup and not with 4.6RC1?

[rvdboom]

BTW, I think your idea of a piglit test would be indeed great, though I guess it's a lot of work.

[mat69]

Look, I think this is really simple. KWin is a lot slower than Compiz using the same hardware and drivers: thus it's obvious where the problem lies. I'm not asking KWin's developers to learn GPU assembly (or whatever) so that I can have some mostly redundant visual effects. But that scenario you described where KWin developers care/target the average hardware/software stack users is not very accurate. On the one hand, the actual status of the graphics drivers was not really taken into account--something that transpired quite clearly from the developer blog posts. After the 4.5 backslash all that guy came up with was a lot of finger pointing. Now, let's imagine that it's true that the drivers are a next-to-useless piece of code. In this case, it would be clearly untrue that KWin's development target the average Linux user, since they would be leaving aside a great chunk of them by not coding around the suppossed limitations in the drivers (I believe this is how things are usually done for games and other applications).

Well funny fact is that it worked great before 4.4. Now you might ask why when nothing changed in 4.5 for most effects?
Simply because the free drivers said they did not support feature X before and thus it was done differently, but the new drivers started saying they supported feature X while that was only partially the case or not true.
Great way to abide the standard.

And yeah I know the reasons for that from the drivers devs -- they posted it here -- yet pointing the blame on KWin for their mess-up is not that great.
Many people bitched and moaned on the KDE 4.0 release and I came to the conclusion that they were to a large degree right, yet maybe not in they way they did it.
No the release anouncements weren't suggesting that this was a dev-release, they are still up you can read them. Some bloggers have said it wasn't to be used by the masses, but well that is not an release anouncement.
So what could have been a more sensible way for the driver devs would have been to not enable partially or not implemented features as "supported" while they were not. Instead a config-option or a compile-option should have done this.


That KWin is a lot slower for many (all?) than compiz is a different story. Personally I don't know the reason for that, if it is a driver issue, bad design, bad implementation or whatever.
I haven't looked at the KWin code and neither do I know OpenGL to say which way should be prefered for performance reason.