@all people experiencing slow Composite performance (like with maximizing/minimizing) with Ubuntu 9.04 (Gnome or KDE):
add this ppa repository to your APT sources and upgrade the Xserver to a fixed one:
Click me, I am of help!
Using the open drivers in Jaunty with a 200M you can notice a slight delay with Compiz while maximizing/minimizing. Kwin is not that bad, but you can indeed notice some lag when maximizing/minimizing as well. Using xterm with the open drivers is smooth as silk however, whereas with fglrx its simply painful; Metacity takes at least 3 seconds to update, and Kwin bogs down to a crawl.
@all people experiencing slow Composite performance (like with maximizing/minimizing) with Ubuntu 9.04 (Gnome or KDE):
add this ppa repository to your APT sources and upgrade the Xserver to a fixed one:
Click me, I am of help!
Indeed, I can confirm that the xserver from the PPA d2kx provided, works.
Running KDE 4.3 RC1 right now with compositing turned on, on a radeon HD4870 card.
@bridgman: I was indeed aware that the direct cause for this performance regression was the removal of a xorg patch. The reason, however, that I said the fault lay with catalyst is that I was (and still am, to be honest) under the impression that nvidia's blob reaches acceptable performance on their cards. If this incorrect, I apologise.
I do wonder, regardless of where the blame lies, about what can be so computationally intensive about unminimizing a window that, when a certain patch is removed from xorg, the performance for that functionality drops to a level where lag is noticeable.
The fact that this happens tells me that the performance for that operation wasn't too high to start with (although this doesn't HAVE to be the case, I guess that would also depend on the invasiveness of the xorg patch in question).
I assume the window has to be rendered again, but with modern gfx cards that shouldn't be an issue; it is what the hardware is built for![]()
I don't know exactly what is happening here either. I have seen similar performance complaints on all hardware, but I have also seen users who don't seem to have the problem. It's a very high-noise situation. My first thought was something simple like "EXA good, XAA bad" but the user reports didn't seem to exactly match that either.
The time-consuming operation appears to be copying either the entire screen or the unminimized window (not sure which) from video memory to system memory without going through an acceleration API. Depending on how the memory manager has set up caching & prefetching on the video memory (via MTRR or PAT), this could either be very fast or very slow. You can't just leave the memory in a "fast" mode because then changes made by the GPU would be missed by the CPU.
Take all of this with a grain of salt though... I haven't traced through the operation myself or spoken directly with someone who has; this is just what I have been able to distill from all the posts and comments.
I should note however, that with the patch I'm now having problems resuming from suspend.
Hello to everybody
I have changed from fglrx to radeonhd and i it works quit good. Now i have DRI Mesa and Radeonhd working with Software acceleration.
Faster in many situations as the fglrx but is there a possibility to get hardware acceleration to work??? Or in other words is there a posibility to get compiz-fusion to work with radeonhd - dri - mesa ....
I have tried but if there is no r600_dri.so module (My Ati Card:Radeon HD3870) there is no possibility to get hardware accelaration to work.
Thanks for answers.
What you should have right now is hardware EXA (2D) and Xv (video) acceleration but not hardware 3D acceleration. If you don't have EXA and Xv hardware acceleration then you probably need to make sure you have an appropriate drm (kernel graphics) driver.
There's an article link at the front of this thread with a bit more information on 6xx/7xx 3D status.
Last edited by bridgman; 07-07-2009 at 12:48 PM.