Fixing Plasma performance with the open source Radeon driver
Tagged:

So I've finally switched from KDE 3.5.9 to 4.1.2. I tried to do a similar move in the past, but I got really disappointed in Plasma's performance back then. I decided it was my debug enabled build and fled back to where I came from and waited a little bit more.

Now the KDE 4.1 packages finally hit Portage, I tried another time to switch. But again, Plasma's performance in non-debug mode was still really poor. Opening the context menu took several seconds, moving Plasmoids was very sluggish and minimizing windows such that the desktop becomes visible wasn't smooth either. The hardware shouldn't be the problem, a 4 year old ATI Radeon Mobility 9600 should be able to do these simple operations.

I decided to start off with a clean xorg.conf. My current one was generated by the fglrx drivers, years ago, and it has turned in one big mess. But after Xorg -configure Plasma was still slow. After some Googling I hit this page, discussing the MigrationHeuristic option. But I decided to enable every option mentioned in the configuration snippet. It turned out to be a good idea: Plasma was smooth all of a sudden.

Being not exactly sure what caused this improvement, I tracked down which options really made Plasma more-or-less fly. MigrationHeuristic didn't matter, it were the following options in the Driver section which did the trick:

Option "AccelMethod" "EXA"
Option "AccelDFS" "true"

The first option was also mentioned on our Userbase pages, but the second option was definitely required to make Plasma perform well. Excellent, another problem solved.

I have the same card with

I have the same card with the same results as you. It should really be a default configuration, now, to have EXA with AccelDFS. I'm surprised not all distros give that. I think Ubuntu isn't even using it for radeon driver.

By the way the CAPTCHA for this site is really hard. I got it incorrect 5 times -- no idea why. Upper case / lower case maybe.

You should have tried it

You should have tried it before switching to KDE, it has the same effect in KDE3.3+/kwin composite. It was 25x faster for simple operation like moving windows with transparency enabled and effect like that. I did try that when xorg 7 was released in 2005. Radeon+XAA (on a radeon 9100) was slow and crashing X if kwin composite was on and Radeon+EXA was totally flying. It is just a fact, EXA is always better if you have transparency with the radeon driver. Old compiz had some trouble with EXA and it is why it is not by default for this driver. Other composite manager like xcomposite and kcomposite (KDE3) work a lot better with EXA.

Re:

The hardware shouldn't be the problem, a 4 year old ATI Radeon Mobility 9600 should be able to do these simple operations. a level coursework | assignment help

Thank you! Now I know what

Thank you! Now I know what to do with on my desktop with a Radeon 9800 Pro. However, instead of switching back to KDE3, I simply disabled desktop effects and then KDE4 flew for me too.

FBTexPercent

Another option that can help is FBTexPercent. It apparently controls the amount of offscreen video memory used for EXA pixmaps. If set to zero, no offscreen memory is used for EXA pixmaps and all is used for GL stuff. Surprisingly, setting it to zero has improved performance for me with EXA. I think it may be because EXA on some or all Radeons makes use of 3d acceleration to accelerate EXA. Then again, I know pretty much nothing about the internals of the graphics drivers, so presume that I'm talking bullshit. In any case, setting it to zero "feels" faster than setting it to 50 (default) or 100. I think some of the x11perf and glxgears stats corroborated my feelings.

Which open source driver

Just to be sure, but which open source radeon driver are you talking about? The radeonhd driver or the ati one?

Sorry

My previous comment was meant to be a reply to the original article.

radeon.ko

This is about the "ati" driver, also known as "radeon" but not "radeonhd".

"Amount of video RAM to

"Amount of video RAM to reserve for OpenGL textures, in percent."

Straight from the man page - 0 means no OpenGL textures can touch the video ram, not the inverse.

For my ATI r100-based card,

For my ATI r100-based card, these options make kde4 even perform slower. kde4-performance is unusable slow for me, so I have to stay with kde3 Sad

This will not work on Fedora

This will not work on Fedora 10 and older radeon r3xx,r4xx AGP. DFS is broken in EXA for some cards (unknown why)

That's bad. Do you know

That's bad. Do you know which radeons in particular are affected? I've tested Radeon 9600, 9600 Pro, 9800 and X200M and they all work much better with EXA+DFS! It should atleast be default for KDE4 distros using these cards.

Default

It should not be the default unless it's known to work reliably and not to cause regressions (which is clearly not the case, at least on Fedora 10), and at that point I'm sure it will become the default in upstream X.Org. I'm sure it's not the default for a reason.

Your solution seems to be Working !!

Hi,

I did a good amount of research for the entire day on Sunday May 10, 2009

Finally on 12th May I came across your post following the link http://www.bramschoenmakers.nl/en/node/549

After implementing your solution provided :-

THE CPU percentage for Xorg process has considerably reduced.

I can use Firefox tabs with ease ( almost immediate response to mouse click )

Also when I click any icon in Dolphin, it opens up almost immediately

I am thankful to you Bram Schoenmakers for your valuable solution.

I have also referred your post at https://bugzilla.redhat.com/show_bug.cgi?id=477969 and https://bugzilla.redhat.com/show_bug.cgi?id=469577

My hardware is IBM THINKPAD R40 with ATI Mobility Radeon R40 ( R100 based chip )

i am running Fedora 10

Regards,
Shadab