KDE SC 4.6 Release Candidate 1 Makes It Out

[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.

[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]

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]

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]

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.

[yotambien]

I got the record straight.
If your drivers don't support a feature it won't be used. And it is not like KWin asks for some highly advanced features.

Yeah that drivers report bullshit is still not the KWin devs' fault. Drivers bullshitting you really sucks e.g. http://joostdevblog.blogspot.com/201...velopment.html

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).

Note that I'm not really talking about some flashy effects that may need some OpenGL feature that perhaps only recently was implemented in the OSS drivers. What I have in mind is the whole composite desktop experience, which suffers from bad performance all around the place. For some people this doesn't matter much. For me it just means that I don't use compositing. I'm perfectly OK with that though.

[mat69]

Wait.
It is ok to bash KDE on every occation, be it crappy grahpics drivers, crappy dbus or whatever. But got forsake never do that on a distro.

There are so many different libraries versions are involved -- especially when talking of Arch is this is nearly always up to date -- that it is hard to find the real causes of problems.

[mat69]

You don't need nepomuk for akonadi.

Holy cow, that is what I said.

If you did not understood the sentence that means that you simply don't have to use nepomuk if you don't want to.
Yes you'll have less features but it will still work.

Uhm, not so sure about it. You may remember that big bug/request about fake transparency (not a KWin example, I guess). The problem was that the only way to get that kind of eye candy is through compositing. The answer from KDE people was around the lines of "abandon your ancient hardware and buy a new graphics card". They only had to add: "and develop the drivers". They even got a patch to add this feature--which I happened to like and use in KDE 3.5 times--but they didn't accept it. It has to be said that KDE4 has some nice effects here and there that don't require compositing, though.

IIRC this was mostly about Plasma not KWin. And the argumentation was along the lines to not "polute" the code.
You may agree or disagree to that, yeah from a user's point of view this sucks, but considering the lack of resources it is quite understandable.
What I personally don't understand though is the lack of configuration options to turn transparancey in Plasma off, I hate it when a window is under the taskbar.

Similar story with KWin's compositing effects. They are slow and some of them need I don't know what super-advanced features. Compiz people somehow got it right. I understand that the developer of KWin is a volunteer, and unfortunately he doesn't know how to implement those features in such a way that most people would enjoy an optimal desktop experience. But at least let's get the record straight.

I got the record straight.
If your drivers don't support a feature it won't be used. And it is not like KWin asks for some highly advanced features.

Yeah that drivers report bullshit is still not the KWin devs' fault. Drivers bullshitting you really sucks e.g. http://joostdevblog.blogspot.com/201...velopment.html

[TemplarGR]

What makes people trying to bash Arch in every opportunity is beyond me...

I have Arch and i don't face this issue.

On the contrary, whenever i installed openSUSE i had major problems. Now, i do not try to bash this distro in every opportunity do i?

[kayosiii]

http://hugo-kde.blogspot.com/2010/09/performance-issues-one-script-and-call.html

also possibly this