Bug 28365

Summary: Regression: i965: severe flicker if window is made fullscreen after xrandr
Product: DRI Reporter: Nick Bowler <nbowler>
Component: DRM/IntelAssignee: Jesse Barnes <jbarnes>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: medium Keywords: NEEDINFO
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
update dri2 buffers if drawable serial changes none

Description Nick Bowler 2010-06-02 18:55:13 UTC
This is probably for reasons very similar to bug 28252, but the symptoms (and
test case) are sufficiently different that I decided to file a new bug.

When one uses xrandr to change the screen size while a double-buffered opengl
application is currently running, and then makes the opengl window full screen
(or if the window became fullscreen as the result of changing the screen size),
the result is extreme flickering.  Every other displayed frame is wrong.  An
error message of the form:

  Couldn't reference dri2 back buffer handle 0x00000004: No such file or directory

is spammed to the console.

To reproduce, start with a large-ish display (i.e. 1680x1050 on my laptop),
use the patched glxgears from bug 28252 to add the -override option.  Then run
glxgears -override -geometry 640x480 to create a 640x480 window in the top
left corner, which will work fine.  Next, run xrandr -s 640x480 and watch the
fireworks.

It works the other way, too: start with a screen size of 640x480, create a
1680x1050 window, and then use xrandr to change the screen size to 1680x1050:
same (broken) result.

There is no problem changing the screen size if the opengl window doesn't end
up fullscreen.

I'm using a T500 laptop with a GM45, xserver 1.8.1, git
kernel/mesa/xf86-video-intel.  This is a regression from xf86-video-intel
2.10.0, bisection results follow.

51c75906329a4727e37c8d1f64f257ea9602caa2 is the first bad commit
commit 51c75906329a4727e37c8d1f64f257ea9602caa2
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri May 1 14:52:26 2009 -0700

    DRI2: support new DRI2 APIs
    
    The new interfaces allow for improved buffer swap, and support for the
    SGI_swap_control, SGI_video_sync and OML_sync_control GLX extensions.
    
    The Intel implementation allows page flipping to occur for swaps that
    are full screen and not rotated.
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

:040000 040000 17d0ca1109ed19b19fcb8cbe3dda95542b54ad6f 0459118ce5a3e0bb216df1d461333d9390f7633e M	src

git bisect start
# bad: [6db1e5231b7a0e79611f771d4efea686f7849e04] dri: Protect against NULL dereference following GPU hang.
git bisect bad 6db1e5231b7a0e79611f771d4efea686f7849e04
# good: [091035146463bf1aa6674bff6947d04fc620c18f] configure.ac: Bump version to 2.10.0.
git bisect good 091035146463bf1aa6674bff6947d04fc620c18f
# skip: [323464b8e2669423df573a18fd1137cb3cad6700] XvMC: clean up i830_hwmc.c
git bisect skip 323464b8e2669423df573a18fd1137cb3cad6700
# bad: [44d45d3fa56f121ce89ffe5b28beb48be01a95df] dri: Use size from backing pixmap when creating buffers.
git bisect bad 44d45d3fa56f121ce89ffe5b28beb48be01a95df
# bad: [8199f8f191f8385ef3a228e0ec014a8bbd44002b] i915 XvMC: kill more subpict support remnants
git bisect bad 8199f8f191f8385ef3a228e0ec014a8bbd44002b
# bad: [06f147dc04629a8a1534703be570e7f25e41cdd9] i830_memory: switch cursors to drm_intel_bo
git bisect bad 06f147dc04629a8a1534703be570e7f25e41cdd9
# bad: [40f5f72e30003993bfe298cd634d4f3f56148d4a] Remove dead main.c from reg_dumper/
git bisect bad 40f5f72e30003993bfe298cd634d4f3f56148d4a
# bad: [31bbd7f919f4f1f545dd49861c15e60561c075cb] uxa/uxa-render: Always remove useless repeats during composite.
git bisect bad 31bbd7f919f4f1f545dd49861c15e60561c075cb
# good: [50e07da8094c8c8c593b6eb8c41fc42444851d04] i830: Do not use vtSema when chosing mapping type.
git bisect good 50e07da8094c8c8c593b6eb8c41fc42444851d04
# bad: [96f45c66eed2631eba98ae416c3afdf540fa5c34] DRI2: if the swap condition is satisfied, complete it immediately
git bisect bad 96f45c66eed2631eba98ae416c3afdf540fa5c34
# good: [4902f546be19e3d5bb47f6c75e2199dc4856c0f4] i965: Ensure that URB_FENCE is aligned to 64-bytes
git bisect good 4902f546be19e3d5bb47f6c75e2199dc4856c0f4
# bad: [51c75906329a4727e37c8d1f64f257ea9602caa2] DRI2: support new DRI2 APIs
git bisect bad 51c75906329a4727e37c8d1f64f257ea9602caa2
Comment 1 Jesse Barnes 2010-07-01 15:48:52 UTC
Does this still happen with current bits?  Several fixes landed in xf86-video-intel, xserver, mesa and libdrm and the kernel that may have affected this.
Comment 2 Jesse Barnes 2010-07-02 10:53:25 UTC
Nevermind, I see it does still happen, debugging now.
Comment 3 Jesse Barnes 2010-07-02 12:25:41 UTC
Created attachment 36695 [details] [review]
update dri2 buffers if drawable serial changes

Can you give this patch a try?  It works for me and I think it's a good way of solving this problem.
Comment 4 Nick Bowler 2010-07-04 08:40:19 UTC
Yes, that seems to fix it, thanks.
Comment 5 Chris Wilson 2010-07-04 09:23:12 UTC
This should also fix the cause of:

commit e2615cdeef078dbd2e834b68c437f098a92b941d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat May 29 16:37:12 2010 +0100

    dri: Only flip if the front and back pixmaps match.
    
    An unredirected window (thanks Michel for the reminder) is backed by the
    Screen pixmap, and so uses a reference of that as its front buffer. The
    back buffer is a pixmap appropriately sized for the drawable. When the
    application requests to swap its buffers, obviously we cannot simply
    exchange the front and back buffer as they do not match, but need to copy
    the appropriate region from the back to the front.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

(but not eliminate its necessity.)
Comment 6 Jesse Barnes 2010-07-09 11:32:49 UTC
Final fix sent out to the xorg-devel list with keithp's review.  Should land in xserver master soon.

http://lists.x.org/archives/xorg-devel/2010-July/011048.html
http://lists.x.org/archives/xorg-devel/2010-July/011049.html

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.