KDE SC 4.6 Release Candidate 1 Makes It Out

[gedgon]

Maybe you should open a bug at bugs.kde.org and post a link to it here.

I can't believe, that devs aren't aware about this. UDisks integration is extremely buggy. And it's not only about performance.
For example, using optical drive will drive you crazy. Every mouseover, resizing, unminimizing or even window focus will spin-up disk. Not to mention ejecting.

Over here with KDE 4.5.5, an HD4200 and latest fglrx I get a max of 27% cpu usage on dolphin[...]

So, it's about 26% too much, but really, it's not about KDE SC < 4.6. It's about regressions.

[devius]

Over here with KDE 4.5.5, an HD4200 and latest fglrx I get a max of 27% cpu usage on dolphin (that's 27% of one core) when doing the mouse up and down on the places panel. When resizing it goes up to about 45% max.

[RealNC]

When I resize the panel to the left like you do in the video, I also get through-the-roof CPU utilization.

So I guess I just confirmed it. Maybe you should open a bug at bugs.kde.org and post a link to it here.

[gedgon]

At this point I'm 99.9% sure, that this bug will land in 4.6 release, so i'll be back with SUSE live cd video soon

As I promised, here's video. openSUSE 11.4 Milestone 6.

Regards.

[Shining Arcanine]

I have 8GB of RAM, but nothing related to mtrr shows up on dmesg (using Arch x64). Besides, this seems to appear on Intel IGPs - I'm using a Nvidia card.

Your MTRR is likely misconfigured. Add "enable_mtrr_cleanup mtrr_spare_reg_nr=1" to your kernel parameters and try rebooting.

I am not familiar with Arch Linux, but Gentoo Linux's documentation briefly describes this issue:

http://www.gentoo.org/doc/en/nvidia-guide.xml#doc_chap4

The unofficial wiki is a bit more helpful in describing it:

http://en.gentoo-wiki.com/wiki/MTRR

Gentoo Linux users typically compile their own kernels, so they do not use those parameters I posted, but as long as you have CONFIG_MTRR_SANITIZER in your kernel .config, you can use those parameters to enable it.

By the way, MTRR has nothing to do with your graphics card. It is an x86 feature. All x86 processors support it.

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

[rvdboom]

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

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

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

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