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.
Announcement
Collapse
No announcement yet.
FGLRX Catalyst and Resizing with Desktop Effects
Collapse
X
-
Originally posted by RealNC View PostWhat 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.
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!
Comment
-
Originally posted by bridgman View PostI 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.
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.
Comment
-
Originally posted by RealNC View PostI 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?
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.)
Comment
-
Originally posted by mtippett View Post(Without the quote, it is unclear which part you don't understand.)
Originally posted by mtippett View PostUbuntu'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.Last edited by RealNC; 22 May 2009, 05:51 AM.
Comment
-
Originally posted by RealNC View PostThe 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.
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.
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.
Comment
Comment