FGLRX Catalyst and Resizing with Desktop Effects

[RealNC]

That was never a part of X.Org. It was Ubuntu doing their random stuff. You can't say "slowdown going from X server 1.5.x to 1.6". There never was a slow-down in X.Org. It's an Ubuntu thing only.

[dkasak]

What will suck is the look&feel instead Also, some times I need to resize windows and watch the layout of the contents to decide upon the right size of the window. With disabling the contents while resizing, that can't be done anymore. And that sucks.

Pull yourself together man! As as been pointed out many times before ( and also indirectly by you here ), displaying the window contens while resizing requires a *complete* redraw of all widgets. With modern widget toolkits, this process is a decent benchmark of the driver's XRENDER acceleration. fglrx is using XAA. There is experimental support for 'textured xrender', which we can only assume will accelerate xrender better ( but just crashes the xserver for me ). What you're continually jumping up and down asking for simply isn't going to happen with a 2-line patch. You need much better xrender acceleration, which is no simple task.

Further, making so much noise about not being able to resize a window and see the new widget layout ( quickly ), just makes you sound like some spoilt brat. This use case isn't exactly something that happens all the time. If it DOES happen all the for you, you should switch window managers. Enlightenment-0.17 can remember settings such as window size, location, active desktop, etc. So use it, and when you get all your windows to the size you want, FAR-KING LEAVE THEM THERE!

[RealNC]

I'll put it bluntly: I payed 350 bucks for my card, I want non-retarded window resizes. There.

[energyman]

thanks for the link, bridgeman.

[mtippett]

I haven't yet found the articles I was reading before, but I think the link below was referenced a few times. It's hard to follow but the gist of it seems to be a "garbage on screen" problem whose fix brought a performance problem. I'll keep looking, but others feel free to jump in

https://bugs.launchpad.net/ubuntu/in...er/+bug/254468

There also seems to be some slowdown specific to a KWin version, but even that seems to still be hotly debated.

Further to John's link above, the discussion about about the impact to fglrx is here

https://bugs.launchpad.net/bugs/351186

Note that there is a PPA build without the X Server patch which appears to make performance appropriate for most people.

Also as John has said, this has been confirmed as a GPU to System Memory transfer issue - which is generally expensive for the CPU to do. On intel it is effectively free since GPU and System memory are exactly the same. It just looks like the call was made to get rid of the corruption with Intel at the expense of what appears to be most of the other drivers.

[RealNC]

I don't understand. The only system where fglrx was fast with these operations were the older Ubuntus. Are you talking about X.Org here or Ubuntu? Can you clarify?

[mtippett]

I don't understand. The only system where fglrx was fast with these operations were the older Ubuntus. Are you talking about X.Org here or Ubuntu? Can you clarify?

John's link has all the details about the decision process for the patch.

Ubuntu's Jaunty X server includes an upstream patch that resolves the issue for EXA based Intel drivers. This patch triggers a slow path in the Proprietary Driver.

Most likely that patch is still active upstream and exists in other XOrg Server 1.6.x based distros.

(Without the quote, it is unclear which part you don't understand.)

[RealNC]

(Without the quote, it is unclear which part you don't understand.)

The part I find confusing is that these delays in fglrx are there in X.Org server 1.5.x too, not only 1.6. They exist in Debian, openSUSE and Gentoo, as well as a vanilla X.Org 1.5.3 without any distro patches. This was here forever, *except* for Ubuntu. How is it that it did go by unnoticed for so long. IIRC, fglrx didn't even officially support Ubuntu a while back.

Ubuntu's Jaunty X server includes an upstream patch that resolves the issue for EXA based Intel drivers. This patch triggers a slow path in the Proprietary Driver.

Most likely that patch is still active upstream and exists in other XOrg Server 1.6.x based distros.

Isn't it rather the opposite? Jaunty does not include an upstream patch at all. It rather removes a non-upstream patch (made by Fedora), thus restoring vanilla upstream behavior and consequently resulting in the slow rendering path that is there (and was there) in most other distros too. I believe it would be logical for fglrx to be made to work well with *vanilla, upstream* X.Org rather than expecting non-upstream patches.

[mtippett]

The part I find confusing is that these delays in fglrx are there in X.Org server 1.5.x too, not only 1.6. They exist in Debian, openSUSE and Gentoo, as well as a vanilla X.Org 1.5.3 without any distro patches. This was here forever, *except* for Ubuntu. How is it that it did go by unnoticed for so long. IIRC, fglrx didn't even officially support Ubuntu a while back.

Similar sympton, different cause. Like VT switch hangs.

Isn't it rather the opposite? Jaunty does not include an upstream patch at all. It rather removes a non-upstream patch (made by Fedora), thus restoring vanilla upstream behavior and consequently resulting in the slow rendering path that is there (and was there) in most other distros too. I believe it would be logical for fglrx to be made to work well with *vanilla, upstream* X.Org rather than expecting non-upstream patches.

Okay, I stand corrected. However distributions tend to watch each other and for the end users 'vanilla' is pointless since all the distributions have the patches more or less.

Unfortunately having a singular upstream focus takes us away from the experience that the customers are having. As mentioned previously the cost of not being always tracking "upstream" is an increased ability to support new features on older distributions. Our commercial customers on RHEL and SuSE wouldn't be too pleased that we say update to a new X Server to get this capability.

Even worse, I'd estimate about 2-3 months of lost effort through rework if we had "rolled with the punches" of the upstream DRI changes as the DRI2 groundwork was laid.

[zx2c4]

Six months after this forum topic was started, this problem has not been addressed by ATI, let alone mentioned in the release notes. What's the deal? How can we get this problem fixed? What do we have to do?