Announcement

Collapse
No announcement yet.

FGLRX Catalyst and Resizing with Desktop Effects

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • zx2c4
    started a topic FGLRX Catalyst and Resizing with Desktop Effects

    FGLRX Catalyst and Resizing with Desktop Effects

    Many users, including myself, have experienced the following problem: resizing windows with desktop effects (kwin, compiz, compositing, etc) turned on is excruciatingly slow. But for the most part, other operations are snappy and ordinary. Resizing windows with desktop effects turned on is painful.

    Many have simply said "oh this is an unfortunate driver bug and you'll just have to wait until ATI fixes it," but I am not satisfied with this lackluster response. Sure it's a driver bug, but it seems so dire that there must be some work around, some fix, some anything to make window resizing acceptable.

    Many have "suggested" a few of the standard flags for xorg.conf that are generally used to speed things up, but these suggestions are just guesses and after reading through countless forum posts, it seems like the usual bag of tricks won't work to fix this horrid resizing bug. And assume that disabling desktop effects is out of the question.

    So Phoronix forum members, I look to you for help: how can I have desktop effects and resizing with acceptable speed? I would like to both have my cake and eat it, so to speak. What shall I do?

    Other failed forum attempts so that you don't repeat false solutions:
    http://www.phoronix.com/forums/showthread.php?t=14848
    http://bbs.archlinux.org/viewtopic.php?id=59315
    http://bugs.kde.org/show_bug.cgi?id=165011

    Stats:
    gentoo linux
    x86-64
    xorg 7.4
    xorg server 1.5.3
    fglrx 9.1
    kde 4.2
    qt 4.4.2
    Last edited by zx2c4; 01-30-2009, 02:19 AM.

  • RealNC
    replied
    Grats, he re-invented the already existing patch (107_fedora_dont_backfill_bg_none.patch)

    Leave a comment:


  • zx2c4
    replied
    Taken from a comment on my blog ( http://blog.jasondonenfeld.com/169#comment-404 )

    Hi, I have been pissed off by this problem a long time and assumed it was ATI?s fault. Tonight I made one last effort before ordering a Nvidia graphics card. And I was successful.

    I am running catalyst 9.8 using a Radeon 3850 and have had this re-size/maximize problem as long as long as I have used KDE4. To solve the problem I needed to modify a file in xorg-server. in the code directory it is called ./composite/compalloc.c. Here I commented out most of a function called compNewPixmap. Everything below these lines:

    pPixmap->screen_x = x;
    pPixmap->screen_y = y;

    all the way down to (but not including) the last line:

    return pPixmap;

    After this I am running KDE4 with all desktop effects that I want and without any lag in resizing/maximizing.
    I am running Gentoo, so I just updated the xorg-server source package file and put it back into the source repository, rebuilt the manifest and emerged it again. Voila!

    Leave a comment:


  • Kano
    replied
    Well i prefer KDE 3.5 without compiz or any desktop effect (like with KDE 4). I sometimes even disabled composite in xorg.conf to get vdpau playback absolutely smooth, but that improved with newer drivers that you don't need to do that usually. 2d is really fast then too. But you can not even use something like vdpau on fglrx yet - or say some chosen ones can, the rest can't.

    Leave a comment:


  • energyman
    replied
    http://www.nvnews.net/vbulletin/show...&postcount=719

    it is not like amd is alone in this.

    Leave a comment:


  • RealNC
    replied
    In other words AMD doesn't have a clue what's happening and where the error lies.

    I guess hiring cooks as devs was a mistake

    Leave a comment:


  • mtippett
    replied
    Originally posted by bridgman View Post
    Tested yes, investigated no - we have other people doing that.

    For me the problem occurs with fglrx but not with the open drivers, however other people are reporting different results.

    One of the KDE devs mentioned last night that there are actually two unrelated resizing issues, one which seems to be specific to fglrx and one which occurs on all hardware. In theory one delay is very slow (several seconds) and the other is much shorter (300mS) but we have seen pretty wide variations in reported delays so it's possible the range of delays for these two bugs are actually overlapping and causing the conflicting reports.

    Some users also seem to be running fglrx with compositing but without delays, which is confusing.
    Furthering to what John has said, the key point to remember is that there may indeed be ways that the driver can be improved to accelerate that path. The main problem with this whole issue is the lack of detail and understanding of the events. Unless people start indicating their relevant software inventory (compiz version, X version, driver version, configuration information) it is very difficult to group issues together (with fglrx and without fglrx in the mix).

    People immediately claim regression in the driver, but similar to the so-called regression in performance with new versions of wine, the variable that has changed has been the application itself.

    It is unlikely a bug on either side, but realistically will come down to a acceleration path that is under development for some drivers (explaining the confusion on the other driver situation, unimplemented on other drivers (like fglrx), and a free operation for other drivers (possibly UXA for intel).

    It appears that there is a known trigger for the regression (the change in the X server), and I don't think anyone from AMD has ever said it is a bug with compiz or X. A trade-off decision was made between corruption for one piece of hardware or performance for another. I respect that a decision was made, but I still don't hold it against people about it being a bug.

    Regards,

    Matthew

    Leave a comment:


  • bridgman
    replied
    Tested yes, investigated no - we have other people doing that.

    For me the problem occurs with fglrx but not with the open drivers, however other people are reporting different results.

    One of the KDE devs mentioned last night that there are actually two unrelated resizing issues, one which seems to be specific to fglrx and one which occurs on all hardware. In theory one delay is very slow (several seconds) and the other is much shorter (300mS) but we have seen pretty wide variations in reported delays so it's possible the range of delays for these two bugs are actually overlapping and causing the conflicting reports.

    Some users also seem to be running fglrx with compositing but without delays, which is confusing.
    Last edited by bridgman; 08-03-2009, 11:30 AM.

    Leave a comment:


  • adamk
    replied
    Originally posted by bridgman View Post
    The point is that it *does* seem to be an issue with other drivers. I have seen performance problems reported on hardware from all the major vendors, with a variety of drivers as well.
    But have you tested it yourself? Certainly you have access to a decent range of AMD hardware, right?

    See, that statement has been bothering me for the last week because I never noticed any resizing issues with compiz enabled in FreeBSD on my x1900 or x850. But I couldn't actually compare it to resizing under fglrx, since that driver doesn't exist for FreeBSD.

    So this weekend I installed Ubuntu 9.04 to an extra USB drive. Updated to the latest packages. I did not install Xorg with the dont_backfill patch. Yet resizing under compiz (with the "Normal" resize mode) is as smooth as you can possibly imagine it. Frankly, it actually feels smoother resizing with compiz than without it.

    I then threw a 3650HD into the machine, enabled the restricted drivers, and rebooted. Using the exact same compiz profile, resizing is painful. It stutters. I start moving the mouse down and to the right... The cursor changes, the mouse moves, but the window doesn't resize for a second. And then it jumps down to the new location of the cursor and stops again for a second.

    So now, why should anyone believe that this is not an issue with fglrx?

    Adam

    Leave a comment:


  • zx2c4
    replied
    To raise awareness: http://blog.jasondonenfeld.com/169

    Leave a comment:

Working...
X