Created attachment 21791 [details] xorg.conf System Environment: ---------------------- Host: gm45a Arch: i386 OSD: Fedora release 10 (Cambridge) Kernel: 2.6.28-release Libdrm: (master)c34539e8bb5568b1d6059abf139dd08e07e84eea Mesa: (intel-2008-q4)b9921a9fb2bc937194eac7e80e31d30f81cb6bb1 Xorg: 7.2 Xserver: (server-1.6-branch)32e81074b967716865aef08b66ec29caf0fec2c5 Xf86_video_intel: (xf86-video-intel-2.6-branch) 21c2a0a75bec887413cddde46351b6d87469993f Bug Description: --------------------- 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. Reproduce Steps: --------------------- 1. xinit& 2. gnome-session& 3. xdemo/glsync -s s(n,b)
Created attachment 21793 [details] xorg.0.log
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: Kernel_version: 2.6.29-rc6 Libdrm: (master)2e2e8575b1ed4703653a72ac2b60b75316c388d7 Mesa: (mesa_7_4_branch)a8528a2e8653b5237c1d1d66fe98c6e031d007f9 Xserver: (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e Xf86_video_intel: (2.7)238c2c40afd9f8b61479b8640d53f20d52fd7ddf
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: (gdb) bt #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: Libdrm: (master)00fae87f96e1fc5198311feec81866bf9c53d0e1 Mesa: (mesa_7_5_branch)fc7f92478286041a018ac4e72d2ccedeea7c0eca Xserver: (server-1.6-branch)5cd5a01259ba349f1868ca4af04207cf120d69e4 Xf86_video_intel: (master)ea0b00e675281b2914450992501566122f9affe0 Kernel_kms: (for-linus)07f4f3e8a24138ca2f3650723d670df25687cd05 And I have noticed the following commit which is to fix this bug is also included in it. commit ec2fde7c8250fdc30984f16c8a1d3587d70b0144 Author: Jesse Barnes <jbarnes@virtuousgeek.org> 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. How we collect and use information is described in our Privacy Policy.