|Summary:||[855gm/865G gem-classic gem]run glxgears get a black window|
|Component:||Drivers/DRI/i915||Assignee:||Eric Anholt <eric>|
|Status:||VERIFIED FIXED||QA Contact:|
|Priority:||high||CC:||eich, kent.liu, libv, ling.yue, mat, michael.meeks, quanxian.wang, shuang.he, sndirsch|
|i915 platform:||i915 features:|
|Bug Depends on:||18283|
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 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 <firstname.lastname@example.org> 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