FGLRX Catalyst and Resizing with Desktop Effects

[bridgman]

It's not a driver issue AFAIK, so not sure why we would mention it in the release notes.

[samile]

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.

[bridgman]

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.

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.

[samile]

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.

[zx2c4]

To raise awareness: http://blog.jasondonenfeld.com/169

[adamk]

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

[bridgman]

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.

[mtippett]

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

[RealNC]

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

[energyman]

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

it is not like amd is alone in this.