Page 12 of 13 FirstFirst ... 210111213 LastLast
Results 111 to 120 of 123

Thread: FGLRX Catalyst and Resizing with Desktop Effects

  1. #111
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,575

    Default

    It's not a driver issue AFAIK, so not sure why we would mention it in the release notes.
    Last edited by bridgman; 07-02-2009 at 08:05 PM.

  2. #112

    Default

    Quote Originally Posted by bridgman View Post
    It's not a driver issue AFAIK, so not sure why we would mention it in the release notes.
    If it's not a driver issue then why is it not an issue with other drivers?
    And if you know it's not a driver issue would you be kind enough to tell us what the issue is so we can pursue it in the correct channels?

    Many thanks.

    Running XFCE, just downloaded the latest Driver with high hopes but still no luck.

  3. #113
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,575

    Default

    Quote Originally Posted by samile View Post
    If it's not a driver issue then why is it not an issue with other drivers?
    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. In general, the reports indicated that the problem affected any graphics card with discrete vram (rather than shared memory on an IGP), and even seemed to affect IGPs when running drivers which were not able to optimize the vram-to-system-memory readback by taking advantage of the fact that the IGP put the framebuffer in a reserved area of system memory, allowing fast copies. The reported IGP problems may have been when sideport memory was used, which is a small block of vram used on an IGP to increase performance and reduce idle power.

    The varying reports of performance impact with discrete cards may be related to XAA vs EXA, or to the amount of CPU power - not sure yet. I upgraded my system recently to an rv620 on Jaunty, which has EXA acceleration but not XAA, but the system also has a fast quad-core CPU so jury is still out.

    Quote Originally Posted by samile View Post
    And if you know it's not a driver issue would you be kind enough to tell us what the issue is so we can pursue it in the correct channels?
    Here is the best discussion I have found about the underlying issue :

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

    The optimization in question (which was *removed* in 9.04, the patch puts it *back*, is desribed as :

    - 107_fedora_dont_backfill_bg_none.patch
    Disable backfilling of windows created with bg=none, which
    otherwise would force a framebuffer readback.

    Note that this is a "go fast" patch; later discussion talks about a 'go slow" patch which backs out the optimization

    I believe the optimization became an issue when KDE4 hit, since it resulted in momentary garbage appearing on the screen with certain hardware (Intel IGPs mostly, but it was also reported occasionally on NVidia and ATI/AMD hardware). Removing the optimization made the "flashing garbage" problem go away, and did not cause obvious performance problems on Intel IGP hardware since IGP parts don't have dedicated vram for the framebuffer (so readbacks are fast).

    Discussion started around post 30 :

    Bryce : "Timo, what are your thoughts on dropping xserver patch 107_fedora_dont_backfill_bg_none.patch ?"

    Timo : "it's a tradeoff performance-wise... it was dropped last time for feisty, but added back quickly when people complained about the lower performance."

    Further discussion boiled down to "Feisty was a while ago, maybe the performance problem has gone away, let's disable the patch and see what the performance impact looks like"

    Around post 39 the "flashing garbage with KDE4" issue first got flagged as a potential security problem.

    The first feedback on performance problems started around post #60, where a user posted that the performance had slowed to the point that compositing was unuseable, and that the problem happened with both fglrx and the open source drivers.

    The original bug ticket ended there, with the removal of the performance optimization for 9.04. At that point three NEW bug tickets started up, talking about the loss of performance resulting from the removal of the 107 optimization patch.
    Last edited by bridgman; 07-23-2009 at 11:34 PM.

  4. #114

    Default

    Wow thanks for the quick and full answer.
    I'm going to wade through the associated bug reports now.
    Sorry for the uninformed questions, and thanks again.

  5. #115
    Join Date
    Jan 2009
    Posts
    24

  6. #116
    Join Date
    May 2007
    Posts
    352

    Default

    Quote 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

  7. #117
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,575

    Default

    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 at 12:30 PM.

  8. #118
    Join Date
    Jun 2006
    Posts
    311

    Default

    Quote 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

  9. #119
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,801

    Default

    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

  10. #120
    Join Date
    Jul 2008
    Posts
    1,731

    Default

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

    it is not like amd is alone in this.

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
  •