| Summary: | [855gm/865G gem-classic gem]run glxgears get a black window | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | liuhaien <haien.liu> |
| Component: | Drivers/DRI/i915 | Assignee: | 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. |
||
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: Libdrm: (master)7e4e0fbbb82b0467d46386bcac1115812aaa1393 Mesa: (master)8d95e66cf78921cd067c4bcf6a1053a7ec3a2ed4 Xserver: (master)065d2afb0ca34f89806e0936c51cd27805bc5123 Xf86_video_intel: (master)d978cd4b453ea588ed2fc2f2cb4ec26856fe00d4 Gem_kernel: (for-airlied)029fc2634651b8156b33857e7c3394125b957e67 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? 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. 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.
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