Created attachment 19468 [details]
mesa intel-2008-q3 branch
drm shipped with kernel 2.6.27-rc6
libdrm master branch
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:
#0 0x0016e9ec in memcpy () from /lib/libc.so.6
#1 0xb7c9697f in dri_fake_reloc_and_validate_buffer (bo=0x83283f8)
#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)
#5 0xb7ccfcc2 in intelCopyBuffer (dPriv=0x8051210, rect=0x0)
#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)
#9 0x0804a768 in main (argc=1, argv=0xbf86a8d4) at glxgears.c:524
Created attachment 19469 [details]
xorg conf file
it works well with mesa-7.2-branch.
*** Bug 18275 has been marked as a duplicate of this bug. ***
Is there any progress on this issue?
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.
Since Kent asked me about the severity/priority.
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.
When do you think you can do the code revert for 855/865? How complicated will the fix be?
Disabling vblank via ~/.drirc didn't help.
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 ...
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.
IMHO this is a blocker.
this issue still exists with the latest driver:
So this blocks not only gem-classic, but also gem.
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.
(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.
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).
Dave, would you commit the patch?
Author: Dave Airlie <email@example.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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.