Resizing issue with Compositing

[ld6772]

Hello,
I am using fglrx (8.12 8.561-1) on OpenSUSE 11.1 x86_64. My card is a Mobility Radeon HD 3650.

When I am using compositing, both with KWin and Compiz resizing windows takes a considerably long time.

The device section of xorg.conf looks like this:

Section "Device"
Identifier "Device[0]"
Driver "fglrx"
VendorName "ATI"
BoardName "Mobility Radeon HD 3650"
Option "Capabilities" "0x00000000"
Option "OpenGLOverlay" "off"
Option "FSAAScale" "0"
Option "FSAAEnable" "off"
Option "VideoOverlay" "on"
#Option "XAANoOffscreenPixmaps" "true"
Option "AccelMethod" "EXA"
Option "UseFastTLS" "2"
BusID "PCI:1:0:0"
EndSection

But I get this output in Xorg.0.log:

(WW) fglrx(0): Unknown vendor-specific block f
(WW) fglrx(0): Option "FSAAScale" is not used
(WW) fglrx(0): Option "FSAAEnable" is not used
(WW) fglrx(0): Option "AccelMethod" is not used
(WW) fglrx(0): Option "CalcAlgorithm" is not used
(WW) fglrx(0): Option "PreferredMode" is not used


I would be most grateful for help on this.

[bridgman]

Removing the XAANoOffscreenPixmaps line might help. I don't think you want to use VideoOverlay on an HDxxxx GPU.

Taking out the other "not used" lines won't make any difference but will make it a bit easier to see error messages.

[ld6772]

Removing the XAANoOffscreenPixmaps line might help. I don't think you want to use VideoOverlay on an HDxxxx GPU.

Taking out the other "not used" lines won't make any difference but will make it a bit easier to see error messages.

Thanks for the quick response...
The The XAANoOffscreenPixmaps line was already commented out, I commented out the VideoOverlay and that seems to have made no difference, windows still take a few seconds to resize.

[RealNC]

This is normal with ATI's drivers and there's nothing you can do about it, sorry :P You have to wait for ATI to fix the drivers (we've been waiting for a looong time though.)

[Melcar]

I always hated how OpenSuse bloats xorg.conf. Anyway, take out the XAANoOffscreenPixmaps option as well as the VideoOverlay one. I don't think fglrx can use EXA, so you should take that out as well. You may want to take out UseFastTLS as well. This is how my xorg.conf looks like:

Section "Monitor"
Identifier "aticonfig-Monitor[0]-0"
Option "VendorName" "ATI Proprietary Driver"
Option "ModelName" "Generic Autodetecting Monitor"
Option "DPMS" "true"
EndSection

Section "Device"
Identifier "aticonfig-Device[0]-0"
Driver "fglrx"
BusID "PCI:1:0:0"
EndSection

Section "Screen"
Identifier "aticonfig-Screen[0]-0"
Device "aticonfig-Device[0]-0"
Monitor "aticonfig-Monitor[0]-0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection

I really don't see the need to spam the Device section with anything other than what I have there, unless you want to force a particular behavior (force opengl overlay for example). The driver will load the options it can use once you initialize it.

[ld6772]

I always hated how OpenSuse bloats xorg.conf. Anyway, take out the XAANoOffscreenPixmaps option as well as the VideoOverlay one. I don't think fglrx can use EXA, so you should take that out as well. You may want to take out UseFastTLS as well. This is how my xorg.conf looks like:

Section "Monitor"
Identifier "aticonfig-Monitor[0]-0"
Option "VendorName" "ATI Proprietary Driver"
Option "ModelName" "Generic Autodetecting Monitor"
Option "DPMS" "true"
EndSection

Section "Device"
Identifier "aticonfig-Device[0]-0"
Driver "fglrx"
BusID "PCI:1:0:0"
EndSection

Section "Screen"
Identifier "aticonfig-Screen[0]-0"
Device "aticonfig-Device[0]-0"
Monitor "aticonfig-Monitor[0]-0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection

I really don't see the need to spam the Device section with anything other than what I have there, unless you want to force a particular behavior (force opengl overlay for example). The driver will load the options it can use once you initialize it.


To be fair on OpenSUSE I added a lot of those options after looking around for solutions to the resizing issue.
I've cleaned it up a lot now, thanks.

[ld6772]

This is normal with ATI's drivers and there's nothing you can do about it, sorry :P You have to wait for ATI to fix the drivers (we've been waiting for a looong time though.)

I had a feeling that that was going to be the case. Thanks for the confirmation.

[zx2c4]

still an issue in 9.7...

[poofyyoda]

From what I've seen it is more of a bug in X, just that the slowness is noticed on ATI more. Even on Nvidia, try to resize some of the gnome games, most noticeably gbnibbles, and you will see the exact symptoms that fglrx has on other windows when the backfill functionality is there. Note that, resizing gnibbles is slow regardless of whether the patch is applied or not, implying that the problem is not in the backfill function itself, but that it just exposes a deeper issue.

[Melcar]

The patched xserver that has been floating around fixes this issue, but the downside is that you get artifacts on-screen.

[bridgman]

The artifacts were only observed on Intel IGP parts AFAIK (that's why the optimization was removed from the X server, and why it was felt to be safe to use the re-patched server for non-Intel hardware) - are the artifacts (essentially a window full of garbage, which might include old screen data) now being reported on other hardware as well ?

[neyz]

I have no idea but it's more than frustrating to not be able to use KDE4's desktop to it's full potential because of this problem. And more than that, if the problem is fixed it will probably be in 1.6 but then fglrx would need to support 1.6 which isn't the case yet if i'm not mistaken ^^

Cheers !

[BlackStar]

The artifacts were only observed on Intel IGP parts AFAIK (that's why the optimization was removed from the X server, and why it was felt to be safe to use the re-patched server for non-Intel hardware) - are the artifacts (essentially a window full of garbage, which might include old screen data) now being reported on other hardware as well ?

Nope, the garbage is (and has always been) visible with fglrx. It appears on all hardware I've tested (R300, R500 and R700), but it is completely innocuous: the effect is similar to a scrambled pixmap (imagine trying to decode a pixmap using a wrong line stride) and it's visible for just a few hundred milliseconds. This might be different on Intel hardware, but it's absolutely impossible to glean any recognizable information from the scrambled image on fglrx.

Of course, the ideal would be for the driver to work correctly with upstream Xorg (no garbage at all). Using the no-backfill patch is a workaround for poor driver performance in this specific code path.

On another note, slow gnibbles resizes have absolutely nothing to do with this patch. This is a matter of slow updates upon expose events, probably due to the specific game logic or the amount of graphics on display.

[bridgman]

Yeah, it's not clear how this is going to shake out. Most of the discussion when this issue first tipped up (KDE4 showing garbage for a long time on certain hardware) seemed to focus on the difference between how Gnome/Compiz and KDE/KWin handled things. The early conclusion seemed to be that Gnome did things right, KDE did not, but even so the 107-fedora-dont-backfill optimization had to be pulled "for security reasons".

The core issue still seems to remain unresolved, however. The conclusion seemed to be that the X protocol is unclear how this situation should be handled, so different groups came up with different ways to work around the problem. Each group declared the others solution a "hack", one set of hacks replaced the other, and here we are ;(

I haven't seen any signs that KDE4.x is going to change to match what was working with Gnome/Compiz, and discussion on the core issue seems to have ground to a halt, so we may end up having to "replace support for the old hack with support for the new hack" in order to get performance back.

XDC is coming up soon, so it might be possible to get the underlying issue discussed and resolved for good. I'll ask around and see what the chances are.

[tball]

Why is everyone saying its an fglrx issue?
If you patch a xserver with the dont_backfill_bg patch, then you will have a fast responding desktop with composite.

I have made a package for Arch named xorg-server-catalyst-maximize-fix in aur. It works just fine.

Try see if you can find a similar patched xorg-server for suse.

http://aur.archlinux.org/packages.php?ID=26687

[adamk]

Why is everyone saying its an fglrx issue?


Maybe because the open source drivers can do resizing flawlessly?

Adam