It's not a driver issue AFAIK, so not sure why we would mention it in the release notes.
Announcement
Collapse
No announcement yet.
FGLRX Catalyst and Resizing with Desktop Effects
Collapse
X
-
Originally posted by bridgman View PostIt's not a driver issue AFAIK, so not sure why we would mention it in the release notes.
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.
Comment
-
Originally posted by samile View PostIf it's not a driver issue then why is it not an issue with other drivers?
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.
Originally posted by samile View PostAnd 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?
[Important bug] This bug is an epic fail, because: * it is a security bug: * every time you switch windows, open menus, or LOCK THE SCREEN or start SCREEN SAVER, any people near by can see what was on your screen some time ago (random pixmaps). * this can show up your emails * this can show up your important documents (think: work and NDAs, and so on) * this can show p0rn to your children (heh...) * this can show your passwords (think: copy paste a password receiv...
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; 23 July 2009, 10:34 PM.Test signature
Comment
-
-
Originally posted by bridgman View PostThe 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.
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
Comment
-
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; 03 August 2009, 11:30 AM.Test signature
Comment
-
Originally posted by bridgman View PostTested 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.
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
Comment
-
it is not like amd is alone in this.
Comment
Comment