Created attachment 35858 [details] [review]
glxgears: Add option to enable override redirect.
Displaying an OpenGL window which is wider than the current framebuffer results
in graphical corruption and/or a GPU hang. I have even seen the screen's DPI
setting magically change as a result, suggesting some more insidious memory
corruption is at play.
To make things more interesting, the issue only occurs if the OpenGL window is
the only thing visible on the entire screen. For example, to reproduce on a
1680x1050 laptop screen, I run glxgears -geometry 2000x1500 (which works fine),
then reposition the window so that the OpenGL area extends beyond all four
sides of the screen (still working fine) and finally set the window's layer to
be above all other windows (including my panels), at which point the corruption
I have attached a patch for glxgears (against mesa/demos.git) which allows one
to enable override_redirect on the window, making it much easier to reproduce
without any window manager intervention: on a 1680x1050 screen, simply run
glxgears -override -geometry 2000x1500 and boom!
I'm using a T500 laptop with a GM45, xserver 1.8.1, git libdrm, git mesa. Also occurs with mesa 7.8.1.
This is a regression from xf86-video-intel-2.10.0. Bisection results follow.
1a76fa5574e8e8f88ac3518a4e4494e1af301dc1 is the first bad commit
Author: Keith Packard <firstname.lastname@example.org>
Date: Fri Jan 29 23:28:46 2010 -0800
Initialize DRI2 info rec version 4 list of driver names
With DRI2 supporting multiple subsystems, the video driver must
initialize the list of driver names instead of just passing the single
driver name used by Mesa. Without this, the X server will fail to
initialize DRI2 as the numDrivers field in this structure will be
Signed-off-by: Keith Packard <email@example.com>
:040000 040000 649cf372a1096de98cea5bb6f5df159d5b8159d5 49c76ac6b97ed5d3678fbeca3ec5961500bcb9d4 M src
git bisect start
# bad: [b645ec83e0d86f2247b8338ceab60b9502516e70] uxa: Apply the drawable offset to the solid rects
git bisect bad b645ec83e0d86f2247b8338ceab60b9502516e70
# good: [091035146463bf1aa6674bff6947d04fc620c18f] configure.ac: Bump version to 2.10.0.
git bisect good 091035146463bf1aa6674bff6947d04fc620c18f
# bad: [90a971c60769781f53827b469a9be3aab14cf71c] uxa: Only reduce a composite to a BLT if it is wholly contained
git bisect bad 90a971c60769781f53827b469a9be3aab14cf71c
# bad: [086c0e25cac1d3dd0a37def8b5cb82c1c6279edf] i830_memory: rename i830_bind_all_memory to reflect code reality
git bisect bad 086c0e25cac1d3dd0a37def8b5cb82c1c6279edf
# bad: [a86869e6c3131b83a2ad529bc313270a9f45f5bd] Fix an unused variable warning for !INTEL_XVMC.
git bisect bad a86869e6c3131b83a2ad529bc313270a9f45f5bd
# good: [93cd943d41c646c794b8cb5a960d8f0805e15395] intel: Use the compositing-aware colorkey filler instead of homebrew fail.
git bisect good 93cd943d41c646c794b8cb5a960d8f0805e15395
# bad: [6610bcbac51c9ac970128012f0d4566d8cfba000] DRI2: only use version 4 APIs if kernel support exists
git bisect bad 6610bcbac51c9ac970128012f0d4566d8cfba000
# good: [5f93d019dc6311dd16b6792ffb60dbfc45ef3d08] uxa: Adjust uxa_get_color_for_pixmap to match prototype
git bisect good 5f93d019dc6311dd16b6792ffb60dbfc45ef3d08
# good: [918151a7955c26174db80b775205f6ffb4f44ab6] uxa: Fix compatible_formats() for OVER
git bisect good 918151a7955c26174db80b775205f6ffb4f44ab6
# bad: [1a76fa5574e8e8f88ac3518a4e4494e1af301dc1] Initialize DRI2 info rec version 4 list of driver names
git bisect bad 1a76fa5574e8e8f88ac3518a4e4494e1af301dc1
(In reply to comment #0)
> I have even seen the screen's DPI setting magically change as a result,
> suggesting some more insidious memory corruption is at play.
Ignore this bit about the DPI. I just realized that 'xrandr -s ...' changes
DPI (and rightfully so!), and I remembered that I was playing with xrandr
before figuring out that this is reproducible without it.
Nick, can I ask you to retest? On my gm45 [x200s] using mostly current trees, I don't see any corruption with your patched glxgears.
(In reply to comment #2)
> Nick, can I ask you to retest? On my gm45 [x200s] using mostly current trees, I
> don't see any corruption with your patched glxgears.
I pulled the latest changes from xf86-video-intel, but the problem still persists. The corruption I see is quite spectacular, it can't be missed.
However, I discovered that if I run xcompmgr, then my test case works normally.
Created attachment 35870 [details]
Video of the corruption.
Here's a video of what I see on the screen when the GPU is not hanging. It's a little shakey as it's filmed with a handheld camera, and it's very low quality due to bugzilla attachment limits.
The GPU typically hangs after I close glxgears. As usual, a reboot is required to recover.
Hmm, I wonder if this is possibily related (wild stab, not even sure if we're intelligent enough to enable pageflipping in this case...):
Author: Chris Wilson <firstname.lastname@example.org>
Date: Sat May 29 10:39:28 2010 +0100
dri: Use size from backing pixmap when creating buffers.
This avoid using the garbage values stored in the Screen drawable,
instead of the true values which are only maintained in its backing
pixmap. The consequence of using the wrong size was to hand a 1x1
pixmap to metacity/mutter and have it believe it was a full screen
drawable; GPU hangs ensued if using page flipping.
I realize it's since been reverted, but I just tested that commit. It doesn't actually solve the problem (GPU still dies), but it does *change* the corruption. A bit hard to describe...
Commit e2615cdeef078 ("dri: Only flip if the front and back pixmaps match.")
plus the subsequent compilation fix seems to have fixed the corruption/hang.
However, these commits have broken vsync for windowed applications:
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
3270 frames in 5.0 seconds = 653.891 FPS
3381 frames in 5.0 seconds = 676.111 FPS
3243 frames in 5.0 seconds = 648.545 FPS
Which commit broke vsync? Do you have any X log messages indicating a problem getting vblank counts?
ah yeah, looks like that last commit will prevent swaps from working correctly even if we end up not flipping...
Created attachment 35993 [details] [review]
Fix exchange validity check
This fix really belongs in the server I think, but it should fix vsync while keeping the flipping fix Chris found.
Yup, with that patch vsync works again and the corruption is gone.
Fix committed, thanks for testing.
Author: Jesse Barnes <email@example.com>
Date: Tue Jun 1 13:46:15 2010 -0700
DRI2: fix new buffer exchange check