Bug 17963

Summary: [855gm/865G gem-classic gem]run glxgears get a black window
Product: Mesa Reporter: liuhaien <haien.liu>
Component: Drivers/DRI/i915Assignee: Eric Anholt <eric>
Status: VERIFIED FIXED QA Contact:
Severity: blocker    
Priority: high CC: eich, kent.liu, libv, ling.yue, mat, michael.meeks, quanxian.wang, shuang.he, sndirsch
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on: 18283    
Bug Blocks: 18841    
Attachments: xorg.0.log
xorg conf file
proposed fix reintroducing old codepaths for 8xx only.

Description liuhaien 2008-10-07 19:43:31 UTC
Created attachment 19468 [details]
xorg.0.log

System Environment:
--------------------------
xf86_video_intel   xf86-video-intel-2.5-branch
       commit ffcbbb071f1cde90fe0dc4887a05dd66c0e66985

mesa   intel-2008-q3 branch
       commit 793c3b9710def008d493135493b754d4cb56333e

drm   shipped with kernel 2.6.27-rc6

libdrm  master branch
       commit ce40261012d39e1096442ef48c45b305c8d69dbd
xserver 1.5.1

Bug detailed description:
--------------------------
start X with gem-classic,then run glxgears, we will get a black window.and it only happens on 855gm .following is the backtrace from gdb and ctrl+c:
backtrace:
#0  0x0016e9ec in memcpy () from /lib/libc.so.6
#1  0xb7c9697f in dri_fake_reloc_and_validate_buffer (bo=0x83283f8)
    at intel_bufmgr_fake.c:1057
#2  0xb7c96c1c in dri_fake_bo_exec (bo=0x83283f8, used=872,
    cliprects=0x8327bd8, num_cliprects=1, DR4=0) at intel_bufmgr_fake.c:1277
#3  0xb7c94f8e in dri_bo_exec (bo=0x83283f8, used=872, cliprects=0x8327bd8,
    num_cliprects=1, DR4=0) at intel_bufmgr.c:135
#4  0xb7cc56fd in _intel_batchbuffer_flush (batch=0x80786e8,
    file=0xb7e750f4 "../intel/intel_batchbuffer.h", line=123)
    at intel_batchbuffer.c:152
#5  0xb7ccfcc2 in intelCopyBuffer (dPriv=0x8051210, rect=0x0)
    at ../intel/intel_batchbuffer.h:123
#6  0xb7ccdf23 in intelSwapBuffers (dPriv=0x8051210) at intel_buffers.c:809
#7  0xb7cbae27 in driSwapBuffers (dPriv=0x8051210) at ../common/dri_util.c:466
#8  0xb7f1f7b9 in glXSwapBuffers (dpy=0x804c008, drawable=6291458)
    at glxcmds.c:852
#9  0x0804a768 in main (argc=1, argv=0xbf86a8d4) at glxgears.c:524


Reproduce steps:
----------------
1.xinit&
2. glxgears
Comment 1 liuhaien 2008-10-07 19:43:57 UTC
Created attachment 19469 [details]
xorg conf file
Comment 2 liuhaien 2008-10-07 23:41:56 UTC
it works well with mesa-7.2-branch.
Comment 3 Gordon Jin 2008-10-28 18:42:43 UTC
*** Bug 18275 has been marked as a duplicate of this bug. ***
Comment 4 Kent Liu 2008-10-28 19:36:58 UTC
Is there any progress on this issue?
Comment 5 Stefan Dirsch 2008-10-29 11:10:00 UTC
I'm seing exactly the same issue on my 855GM *and* with 865G.

Used components are Intel Q3 release:

- xorg-server 1.5.2
- xf86-video-intel 2.5.0
- libdrm > 2.4.0 (commit a59ea02)
- Mesa 'intel-2008-q3' branch, commit 46921a5

Afer switching back to Mesa 7.2 glxgears works again.
Comment 6 Stefan Dirsch 2008-11-05 22:28:11 UTC
Since Kent asked me about the severity/priority.
Comment 7 Eric Anholt 2008-11-10 17:50:57 UTC
I was poking at this today trying to bring the hardware up to reproduce a different bug, and my suspicion is that the VB support doesn't actually exist on 855/865 (though it did on 830/845), so the VB path needs to be reverted on pre-9xx.

I don't have time to do that at the moment.
Comment 8 Kent Liu 2008-11-10 23:36:46 UTC
When do you think you can do the code revert for 855/865? How complicated will the fix be?
Comment 9 Stefan Dirsch 2008-11-11 00:06:54 UTC
Disabling vblank via ~/.drirc didn't help.
Comment 10 Stefan Dirsch 2008-11-18 14:03:23 UTC
In case you don't have time to fix this issue, I suggest to at least disable non-functional 3D hardware acceleration for 855/865. Slow software rendering is still better than black OpenGL windows ...
Comment 11 Stefan Dirsch 2008-11-22 02:52:39 UTC
I'm wondering if there is a plan (+schedule) to address this issue by Intel. Disabling 3D acceleration on 855GM/865G wouldn't be really nice, but at least better than complete broken OpenGL support on these chipsets.
Comment 12 Stefan Dirsch 2008-11-22 03:06:31 UTC
IMHO this is a blocker.
Comment 13 liuhaien 2008-11-25 23:20:29 UTC
this issue still exists with the latest driver:
Libdrm:		(master)7e4e0fbbb82b0467d46386bcac1115812aaa1393
Mesa:		(master)8d95e66cf78921cd067c4bcf6a1053a7ec3a2ed4
Xserver:		(master)065d2afb0ca34f89806e0936c51cd27805bc5123
Xf86_video_intel:		(master)d978cd4b453ea588ed2fc2f2cb4ec26856fe00d4
Gem_kernel: (for-airlied)029fc2634651b8156b33857e7c3394125b957e67
Comment 14 Gordon Jin 2008-11-26 00:12:28 UTC
So this blocks not only gem-classic, but also gem.
Comment 15 Dave Airlie 2008-11-27 17:50:15 UTC
Created attachment 20645 [details] [review]
proposed fix reintroducing old codepaths for 8xx only.

This fix works for me, just need to make sure it doesn't regress anything else.

Please test and let me know.
Comment 16 liuhaien 2008-11-27 19:01:26 UTC
(In reply to comment #15)
> Created an attachment (id=20645) [details]
> proposed fix reintroducing old codepaths for 8xx only.
> 
> This fix works for me, just need to make sure it doesn't regress anything else.
> 
> Please test and let me know.
> 

your patch also works for me ,and I don't see any regressions. 
Comment 17 Stefan Dirsch 2008-11-28 03:14:49 UTC
Thanks, David. Your patch definitely fixes OpenGL support for 8xx. Tested successfully on two different i845 machines (FSC and Dell Optiplex 260) and one 855GM laptop (HP Compaq NX5000).
Comment 18 Gordon Jin 2008-12-01 17:56:22 UTC
Dave, would you commit the patch?
Comment 19 Eric Anholt 2008-12-02 13:54:54 UTC
commit cd031749a75883a6fbf8fb7bf989b77a7c705819
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Nov 28 19:38:47 2008 +1000

    intel: restore old vertex submit paths for i8xx hardware.
    
    Intel docs state that only 830/845 have VBOs, 855/865 don't. So
    lets just not use them on i8xx at all.
    
    This restores the old pre-vbo code and uses it on all 8xx hw.
Comment 20 liuhaien 2008-12-02 17:56:33 UTC
verified.thanks

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.