Bug 28573

19d8c0cf50e98909c533ebfce3a0dd3f72b755c1 is the first bad commit

commit 19d8c0cf50e98909c533ebfce3a0dd3f72b755c1
Author: Chris Wilson <chris@chris-wilson.co.uk>
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 <chris@chris-wilson.co.uk>

commit 0e0101758438debf98f989d815989b45e78cf5f6
Author: Chris Wilson <chris@chris-wilson.co.uk>
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 <brian@xyzw.org>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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.

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.

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.

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.

Brian, can you share the simple SDL application?

Created attachment 36761 [details]
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.

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?

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.

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

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

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.

commit 53fbc9f1760ee481cba1f6dceb9e7c97282a2976
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Dec 30 15:32:40 2010 +0000

    Don't replace the scanout bo through PutImage
    
    As the bo may be pinned for either use by the scanout or through sharing
    with another application, under those circumstances we cannot replace
    the bo itself but must force the blit for PutImage.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31367
    Reported-and-tested-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>