Bug 28573

Summary: [i965] Fullscreen flash and windowed SDL games fail to update the screen in compiz
Product: xorg Reporter: Brian Rogers <brian>
Component: Driver/intelAssignee: Chris Wilson <chris>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: bryce, chris, tmezzadra
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Vecto program, demonstrates bug none

Description Brian Rogers 2010-06-16 05:26:57 UTC
Fullscreen flash, such as YouTube videos, don't update the screen. Instead, I'm left looking at a static frame. But it isn't a hang and the system otherwise functions normally. If I exit fullscreen mode with the escape key, everything goes back to normal.

Also, SDL-based games do not update when running in a window (I did not check fullscreen mode in this case). Or sometimes they animate for up to 15 seconds, then cease updating. Tested SDL applications were The Ur-Quan Masters and my own very simple SDL application.

This problem only occurs while compiz is running. If I switch to metacity, the SDL window resumes updating, and fullscreen flash works fine. Since I can see the problem in a window, it isn't just a fullscreen page flipping issue.

This is on Ubuntu Lucid + xorg-edgers. There are no error logs or crashes. I will try to bisect this issue in a bit.
Comment 1 Brian Rogers 2010-06-17 01:32:02 UTC
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>
Comment 2 Chris Wilson 2010-06-17 06:47:37 UTC
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>
Comment 3 Brian Rogers 2010-07-04 17:55:46 UTC
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.
Comment 4 Brian Rogers 2010-07-04 18:13:30 UTC
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.
Comment 5 Brian Rogers 2010-07-04 18:29:17 UTC
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.
Comment 6 Brian Rogers 2010-07-04 19:13:54 UTC
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.
Comment 7 Chris Wilson 2010-07-05 00:30:46 UTC
Brian, can you share the simple SDL application?
Comment 8 Brian Rogers 2010-07-05 02:20:19 UTC
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.
Comment 9 Chris Wilson 2010-07-05 03:01:24 UTC
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?
Comment 10 Brian Rogers 2010-07-05 03:51:30 UTC
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.
Comment 11 Chris Wilson 2010-07-14 01:28:10 UTC
*** Bug 29054 has been marked as a duplicate of this bug. ***
Comment 13 Brian Rogers 2010-09-14 06:10:14 UTC
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.
Comment 14 Chris Wilson 2011-01-19 06:34:42 UTC
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>

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.