Created attachment 21791 [details]
OSD: Fedora release 10 (Cambridge)
In UXA mode, glsync will fail both with or without gnome. But in EXA mode, it will pass just under X, if turned on gnome-session it will fail too.
3. xdemo/glsync -s s(n,b)
Created attachment 21793 [details]
Li Peng posted a patch that might help with this by preventing pipe/plane swaps w/DRI2, but I think this is really a more general DRI2 problem...
this issue also happens on 915gm.
on g45 using uxa,glsyn only fails with "-s b". "-s s" works well
Now on gm45-32, with EXA it will be OK both with and without gnome.
And with UXA, it will fail. With the following configuration:
so changing the title to be UXA only.
The -sb failure is a dup of 20664, marking as such (and updating the description of 20664).
*** This bug has been marked as a duplicate of bug 20664 ***
I tested with the newest code in both KMS and UMS mode. In KMS mode, it still fails. In UMS, "glsync -s b" will crash the X with the following info:
#0 I830DRI2CopyRegion (pDraw=0xba8c798, pRegion=0xb8cf608,
pDstBuffer=0xba60390, pSrcBuffer=0xba603a8) at i830_dri.c:322
#1 0xb7ee5cf5 in DRI2CopyRegion (pDraw=0xba8c798, pRegion=0xb8cf608, dest=0,
src=1) at dri2.c:186
#2 0xb7ee65d7 in ProcDRI2CopyRegion () at dri2ext.c:251
#3 ProcDRI2Dispatch (client=0xba53250) at dri2ext.c:296
#4 0x0808676f in Dispatch () at dispatch.c:437
#5 0x0806c69d in main (argc=2, argv=0xbfafe064, envp=Cannot access memory at address 0xa
) at main.c:397
The new code is built with:
And I have noticed the following commit which is to fix this bug is also included in it.
Author: Jesse Barnes <email@example.com>
Date: Tue Jun 2 16:42:56 2009 +0100
Sync DRI2 CopyRegion to vertical retrace
You need a couple of other commits that came after that one, to avoid the crash if we don't find an overlapping crtc. Please reopen if master still has the problem.
I built with all the components in master, and it works well with KMS and UMS. But if I enable compiz, it will refreshed slowly that I can see one frame after another.
That's expected behavior. glsync -sb will swap its contents (this shouldn't wait because its front buffer isn't on-screen), then compiz will grab the front buffer contents and swap that to the screen at some point (which will be synchronized). So you won't get the nice orange effect; you'll get whatever compiz happened to pick up that frame.
OK. Thanks. I verified this bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.