|Summary:||[915gm gm45] glsync fails under UXA|
|Product:||Mesa||Reporter:||zhao jian <jian.j.zhao>|
|Component:||Drivers/DRI/i965||Assignee:||Jesse Barnes <jbarnes>|
|Status:||VERIFIED FIXED||QA Contact:|
|i915 platform:||i915 features:|
|Bug Depends on:|
Description zhao jian 2009-01-08 00:23:08 UTC
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)
Comment 2 Jesse Barnes 2009-01-08 11:10:00 UTC
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...
Comment 3 liuhaien 2009-01-11 23:50:20 UTC
this issue also happens on 915gm.
Comment 4 liuhaien 2009-02-23 18:42:00 UTC
on g45 using uxa,glsyn only fails with "-s b". "-s s" works well
Comment 5 zhao jian 2009-03-18 22:37:16 UTC
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
Comment 6 Gordon Jin 2009-03-21 19:43:15 UTC
so changing the title to be UXA only.
Comment 7 Jesse Barnes 2009-03-30 17:33:29 UTC
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 ***
Comment 8 zhao jian 2009-06-04 02:41:54 UTC
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 <firstname.lastname@example.org> Date: Tue Jun 2 16:42:56 2009 +0100 Sync DRI2 CopyRegion to vertical retrace
Comment 9 Jesse Barnes 2009-06-04 08:26:56 UTC
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.
Comment 10 zhao jian 2009-06-19 01:34:44 UTC
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.
Comment 11 Jesse Barnes 2009-06-19 10:07:11 UTC
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.
Comment 12 zhao jian 2009-06-21 00:25:02 UTC
OK. Thanks. I verified this bug.