Bug 19458

Summary: [915gm gm45] glsync fails under UXA
Product: Mesa Reporter: zhao jian <jian.j.zhao>
Component: Drivers/DRI/i965Assignee: Jesse Barnes <jbarnes>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: medium CC: eric
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 20277    
Attachments: xorg.conf

Description zhao jian 2009-01-08 00:23:08 UTC
Created attachment 21791 [details]

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) 

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 1 zhao jian 2009-01-08 00:29:46 UTC
Created attachment 21793 [details]
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 <jbarnes@virtuousgeek.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. 

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.