Page 11 of 13 FirstFirst ... 910111213 LastLast
Results 101 to 110 of 123

Thread: FGLRX Catalyst and Resizing with Desktop Effects

  1. #101
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    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.

  2. #102
    Join Date
    Sep 2007
    Posts
    30

    Default

    Quote Originally Posted by RealNC View Post
    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!

  3. #103
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

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

  4. #104
    Join Date
    Jul 2008
    Posts
    1,718

    Default

    thanks for the link, bridgeman.

  5. #105
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by bridgman View Post
    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.

  6. #106
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    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?

  7. #107
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by RealNC View Post
    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.)

  8. #108
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    Quote Originally Posted by mtippett View Post
    (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.


    Quote Originally Posted by mtippett View Post
    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.
    Last edited by RealNC; 05-22-2009 at 05:51 AM.

  9. #109
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote Originally Posted by RealNC View Post
    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.

  10. #110
    Join Date
    Jan 2009
    Posts
    24

    Default

    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?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •