[q35] compiz causes SDL surfaces to stop animating

[Kees Cook]

Binary package hint: compiz

I've noticed that a number of SDL applications do not animate any more when run under compiz. Attaching an example that shows this. (It should animate forever, but under current compiz (i915 driver drm) for me, it will hang immediately or after a few seconds.)

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: compiz 1:0.8.4-0ubuntu16
ProcVersionSignature: Ubuntu 2.6.34-5.14-generic 2.6.34
Uname: Linux 2.6.34-5-generic x86_64
Architecture: amd64
CompizPlugins: [core,ccp,move,resize,place,decoration,text,dbus,regex,commands,imgjpeg,png,gnomecompat,mousepoll,session,svg,neg,resizeinfo,vpswitch,workarounds,animation,snap,fade,cube,scale,expo,rotate,ezoom,scaleaddon,staticswitcher]
Date: Mon Jun 21 20:44:21 2010
PackageArchitecture: all
PciDisplay: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b2] (rev 02)
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.34-5-generic root=/dev/mapper/systemvg-root2lv ro quiet splash
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
RelatedPackageVersions:
 xserver-xorg 1:7.5+6ubuntu1
 libgl1-mesa-glx 7.8.1-3ubuntu2
 libdrm2 2.4.20-2ubuntu1
 xserver-xorg-video-intel 2:2.11.0-1ubuntu2
 xserver-xorg-video-ati 1:6.13.0-2ubuntu2
SourcePackage: compiz
XorgConf:
 Section "ServerFlags"
  Option "DontZap" "False"
 EndSection
dmi.bios.date: 09/22/2008
dmi.bios.vendor: Intel Corp.
dmi.bios.version: JOQ3510J.86A.0954.2008.0922.2331
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DQ35JO
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD82085-800
dmi.chassis.type: 3
dmi.modalias: dmi:bvnIntelCorp.:bvrJOQ3510J.86A.0954.2008.0922.2331:bd09/22/2008:svn:pn:pvr:rvnIntelCorporation:rnDQ35JO:rvrAAD82085-800:cvn:ct3:cvr:
system: distro = Ubuntu, architecture = x86_64, kernel = 2.6.34-5-generic

[Brian Rogers (brian-rogers)]

19d8c0cf50e98909c533ebfce3a0dd3f72b755c1 is the first bad commit

commit 19d8c0cf50e98909c533ebfce3a0dd3f72b755c1
Author: Chris Wilson <email address hidden>
Date: Sun Nov 29 21:16:49 2009 +0000

    uxa: PutImage acceleration

    Avoid waiting on dirty buffer object by streaming the upload to a fresh,
    non-GPU hot buffer and blitting to the destination.

    This should help to redress the regression reported in bug 18075:

      [UXA] XPutImage performance regression
      https://bugs.freedesktop.org/show_bug.cgi?id=18075

    Using the particular synthetic benchmark in question on a g45:

    Before:
       9542.910448 Ops/s; put composition (!); 15x15
       5623.271889 Ops/s; put composition (!); 75x75
       1685.520362 Ops/s; put composition (!); 250x250

    After:
      40173.865300 Ops/s; put composition (!); 15x15
      28670.280612 Ops/s; put composition (!); 75x75
       4794.368601 Ops/s; put composition (!); 250x250

    which while not stellar performance is at least an improvement. As
    anticipated this has little impact on the non-fallback RENDER paths, for
    instance the current cairo-xlib backend is unaffected by this change.

    Signed-off-by: Chris Wilson <email address hidden>

[Chris Wilson (ickle)]

commit 0e0101758438debf98f989d815989b45e78cf5f6
Author: Chris Wilson <email address hidden>
Date: Tue Jun 15 12:48:57 2010 +0100

    i830: Tidy i830_uxa_put_image()

    Use a single code path to upload the image data after selecting the
    right bo, and take advantage of pwrite() when possible.

    Fixes:

      Bug 28569 - [i965] IGN's flash-based video player crashes X
      https://bugs.freedesktop.org/show_bug.cgi?id=28569

      Bug 28573 - [i965] Fullscreen flash and windowed SDL games fail to
                  update the screen
      https://bugs.freedesktop.org/show_bug.cgi?id=28573

    Reported-and-tested-by: Brian Rogers <email address hidden>
    Signed-off-by: Chris Wilson <email address hidden>

[Kees Cook (kees)]

Binary package hint: compiz

I've noticed that a number of SDL applications do not animate any more when run under compiz. Attaching an example that shows this. (It should animate forever, but under current compiz (i915 driver drm) for me, it will hang immediately or after a few seconds.)

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: compiz 1:0.8.4-0ubuntu16
ProcVersionSignature: Ubuntu 2.6.34-5.14-generic 2.6.34
Uname: Linux 2.6.34-5-generic x86_64
Architecture: amd64
CompizPlugins: [core,ccp,move,resize,place,decoration,text,dbus,regex,commands,imgjpeg,png,gnomecompat,mousepoll,session,svg,neg,resizeinfo,vpswitch,workarounds,animation,snap,fade,cube,scale,expo,rotate,ezoom,scaleaddon,staticswitcher]
Date: Mon Jun 21 20:44:21 2010
PackageArchitecture: all
PciDisplay: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b2] (rev 02)
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.34-5-generic root=/dev/mapper/systemvg-root2lv ro quiet splash
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
RelatedPackageVersions:
 xserver-xorg 1:7.5+6ubuntu1
 libgl1-mesa-glx 7.8.1-3ubuntu2
 libdrm2 2.4.20-2ubuntu1
 xserver-xorg-video-intel 2:2.11.0-1ubuntu2
 xserver-xorg-video-ati 1:6.13.0-2ubuntu2
SourcePackage: compiz
XorgConf:
 Section "ServerFlags"
  Option "DontZap" "False"
 EndSection
dmi.bios.date: 09/22/2008
dmi.bios.vendor: Intel Corp.
dmi.bios.version: JOQ3510J.86A.0954.2008.0922.2331
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DQ35JO
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD82085-800
dmi.chassis.type: 3
dmi.modalias: dmi:bvnIntelCorp.:bvrJOQ3510J.86A.0954.2008.0922.2331:bd09/22/2008:svn:pn:pvr:rvnIntelCorporation:rnDQ35JO:rvrAAD82085-800:cvn:ct3:cvr:
system: distro = Ubuntu, architecture = x86_64, kernel = 2.6.34-5-generic

[Chris Halse Rogers (raof)]

I'm pretty sure this is actually https://bugs.freedesktop.org/show_bug.cgi?id=28573 which is fixed in the new 2.12 DDX release.

[Brian Rogers (brian-rogers)]

This bug is back, though it occurs less frequently and requires multiple tries before it happens.

First I'll double-check that 0e0101758438debf98f989d815989b45e78cf5f6 doesn't suffer from the issue at all, then I'll bisect between that and the master branch.

[Brian Rogers (brian-rogers)]

This was not completely fixed with 0e0101758438debf98f989d815989b45e78cf5f6.

I have a simple SDL application that runs in a window and shows an animation. Before that commit, it draws a random number of frames before the animation freezes. Sometimes it produces no frames and the content of the window is just black. Starting with the above commit, it will either produce a black window or run correctly.

So the problem has been fixed where it always loses the ability to update the screen after drawing a few frames. But there's still a bug where it sometimes fails to draw even the first frame.

[Brian Rogers (brian-rogers)]

The situation with fullscreen flash is similar: before the commit, screen updates were guaranteed to freeze in a few seconds, but sometimes it would freeze immediately.

Now fullscreen mode never freezes once it's working, but if I try fullscreen several times, then in about one in a dozen tries it will only show one frame and not update until I leave fullscreen mode.

[Brian Rogers (brian-rogers)]

The bad commit is still 19d8c0cf, as mentioned in comment 1. That is, both problems are introduced in that commit, and only that one that happened 100% of the time has been fixed.

[Chris Wilson (ickle)]

Brian, can you share the simple SDL application?

[Brian Rogers (brian-rogers)]

Created an attachment (id=36761)
Vecto program, demonstrates bug

Here's my program. I believe the bug affects all SDL applications, but I guess there's a convenience to having a small application that loads and closes instantly.

Open and close this about 20 times, and you'll probably see the problem at least once. The window will be black and won't update.

[Chris Wilson (ickle)]

Thanks Brian, whilst the bug may affect a particular class of program, it is vital to have a test case which is known to fail on your machine. I haven't yet managed to trigger a hang, and the way it only fails infrequently for you, implies a race condition.

The code itself appears sane, it does a ShmPutImage to transfer the bytes directly to the window (so here that will write directly onto the screen frontbuffer) and then immediately does a Sync.

Brian, when it hangs is it still consuming cpu time? i.e. is it simply X no longer updating the window or has it blocked the application as well?

[Brian Rogers (brian-rogers)]

It just stops updating the window. The program is still running behind the scenes. Also, the problem only occurs with compiz running. I don't observe the issue with metacity.

If I switch to metacity while I have a non-updating window, updates resume, and that window continues to work even if I switch back to compiz again.

[Chris Wilson (ickle)]

*** Bug 29054 has been marked as a duplicate of this bug. ***

[Chris Wilson (ickle)]

http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/597094

[Bryce Harrington (bryce)]

Kees Cook - I've forwarded this bug upstream to http://bugs.freedesktop.org/show_bug.cgi?id=29054 - please subscribe yourself to this bug, in case they need further information or wish you to test something. Thanks ahead of time!

[Chris Halse Rogers (raof)]

The sdltest example no longer freezes for me in Maverick, since we've now got 2.12. I think this bug is fixed.

Kees - can you reproduce this with current Maverick, or close the bug?

[Brian Rogers (brian-rogers)]

This bug still exists with the latest version of everything. Just be running compiz and launch an SDL app (such as the attached one) several times. Some of the runs will never produce a screen update, though aside from that they are running normally.

[Timo Aaltonen (tjaalton)]

upstream thinks this is fixed, and no reply saying the contrary in several months -> closing.