If you play high performance games: follow the hardware manager's suggestion.
I intend to eventually play high performance games, I don't see why i have to settle with shitty performance on a good card :/ If i can't even get basic compiz effects like maximise and minimise to work properly, then I can't really go forward. THe hardware manager's suggestion doesn't work.
I used the ubuntu recommended drivers from pop up = fail
I used the ATI 10.5, following their instruction manual = fail
There's still lag, and there's still tearing with moving windows
btw i've been trying these out with fresh installs of ubuntu everytime so as to avoid conflict
A failed proprietary driver install is strange, though: I remember that on my own attempt, it went off without a hitch.
I put it on the highest level. I can't remember what it's called i think it's extra effects (the third option). I left evrything at compiz default setting.
I think i should be able to, the card can take it, there's no game i can't play comfortably, i think it should be able to handle a bit of full blast eye candy. I mean I get lag to maximise a window???? that is kinda ridiculous i think.
I really don't get it...i would really really like to use the proprietary ATI drivers that linux distributed for linux and get my stuff working. This must be some kind of bug right? I'm going to try again later after work, and report exactly what i do from a FRESH install of ubuntu AGAIN. This will probably be my 5th time.
The delay isn't a "bug", it's that when you perform a maximize operation under Compiz the entire screen has to get copied from video memory to system memory. This is accelerated with some acceleration APIs but not with XAA (which is what fglrx uses today), so there's a delay while the data is copied down.
This operation was fast for years as a result of an X server patch that eliminated the (slow) copy, but the patch was removed from the X server in distro releases starting early 2009 so the delay came back. Short term solution is to use a patched version of the X server including the "backclear" patch (most distros offer a repo with a pre-patched server); longer term solution will be replacing XAA with new acceleration code that can accelerate the download.
THank you for the first complete explanation for my problem. I appreciate it very much, now i have some direction.
Any particular reason why distros will remove that patch although it allows for better performance?
Sorry about the multiple post, i opted to post in threads that people seem to follow. I didn't want to start a completely new thread, so i opted to post a few times in ones with a lil traffic
I do not know why distributions removed the patch in 2009 (I think it resulted in problems with the intel opensource driver or something?), but I have a feeling you don't have to wait long at all for the proper solution.
Yeah, there was a new Intel driver which relied on the downloaded data to overwrite old data in newly allocated memory buffers. Nothing wrong with that AFAIK (presumably it was done as a performance optimization) but it interacted badly with the no-backfill patch, allowing users to see old screen info which potentially could have been from another user's session.
The problem was flagged as a security issue and removing the patch was the most expedient way to close it. The result was that any driver running XAA acceleration became very slow when performing certain operations. Felix implemented the backclear patch which performed the same function as no-backfill but also added code to clear out the destination buffer, eliminating the security hole on Intel GPUs while still providing good performance on XAA drivers.
When the 10.6 driver comes out, check the release notes to see if the new 2D acceleration code is enabled by default. If so, give that driver a try and it should address some of the problems you are seeing.
Thank you for the explanation Bridgeman: I remember seeing something about that at the time, yes.
Could it also be the reason why switching workspace is so slow with fglrx? I have a 1-5s delay switching to a workspace that contains open windows (the more windows, the longer the delay).
If 10.6's new code base solves THAT, I can't wait to try it :D