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.
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>
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.