Summary: | Regression: i965: corruption/GPU hang with wide windows. | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Nick Bowler <nbowler> | ||||||||
Component: | DRM/Intel | Assignee: | Jesse Barnes <jbarnes> | ||||||||
Status: | CLOSED FIXED | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | medium | Keywords: | NEEDINFO | ||||||||
Version: | XOrg git | ||||||||||
Hardware: | Other | ||||||||||
OS: | All | ||||||||||
Whiteboard: | |||||||||||
i915 platform: | i915 features: | ||||||||||
Attachments: |
|
Description
Nick Bowler
2010-05-25 16:37:35 UTC
(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...): commit 44d45d3fa56f121ce89ffe5b28beb48be01a95df Author: Chris Wilson <chris@chris-wilson.co.uk> 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: % glxgears 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. commit f2272402035574c206a0e3383c55373c440fd928 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Jun 1 13:46:15 2010 -0700 DRI2: fix new buffer exchange check |
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.