I'm having a zbuffer with VTK and the intel driver. Windows that are "reparented" don't get a zbuffer. Then the inside of my meshes show through. This was discussed in the following thread: https://mail.enthought.com/pipermail/enthought-dev/2008-April/014205.html Also, the following old thread on Mesa3d-users: http://www.nabble.com/Intel-driver-depth-buffer-td13994947.html which was never resolved. And here's an excerpt from the above thread (the gtk example apparently does reparenting, although I should point out I have no idea what that is): $ cd /usr/lib/python2.5/site-packages/vtk/tk $ export MESA_DEBUG=1 $ python vtkTkRenderWindowInteractor.py Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable $ cd /usr/lib/python2.5/site-packages/vtk/gtk $ export MESA_DEBUG=1 $ python GtkGLExtVTKRenderWindowInteractor.py Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable Mesa warning: glEnable(GL_DEPTH_TEST) but no depth buffer Although this does look like a vtk problem, it works fine on other drivers (tested on my radeon r200) and the consensus on the above mailing list was to come here. My video card is: (II) intel(0): Integrated Graphics Chipset: Intel(R) 965GM (--) intel(0): Chipset: "965GM" I'm using the intel-2.3.1-r1 driver on Gentoo, but I've seen the problem in earlier versions too. Others users have the issue on different distros and different driver versions (eg., 2:2.1.1-0ubuntu9.1) Let me know what other information I can provide to help out.
Changing to the correct component as this is 3d driver bug. I wonder which mesa version you're using. Please attach Xorg.0.log.
*** Bug 16363 has been marked as a duplicate of this bug. ***
Created attachment 17147 [details] Xorg.0.log I'm using mesa 7.0.3. I've been waiting to try 7.1rc1 but it doesn't yet build for intel (at least in Gentoo). I've heard that the issue does not appear on Fedora 9 with their pre-release Xorg/Mesa: so I'm hoping once I can run mesa 7.1rc1, the issue will be resolved. I've attached my Xorg.0.log (this is for xorg-server 1.4.0.90). I can attach the log for 1.4.2 once I restart X.
I realized my last comment was a little vague... Here's the message about it working on Fedora 9: https://mail.enthought.com/pipermail/enthought-dev/2008-June/015124.html and a quoting a followup (https://mail.enthought.com/pipermail/enthought-dev/2008-June/015133.html) with versions: X.Org X Server 1.4.99.901 (1.5.0 RC 1) Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-53.1.14.el5xen i686 Current Operating System: Linux localhost.localdomain 2.6.25.4-30.fc9.i686 #1 SMP Wed May 21 18:12:35 EDT 2008 i686 Build Date: 06 May 2008 03:35:07PM Build ID: xorg-x11-server 1.4.99.901-29.20080415.fc9 (II) LoadModule: "intel" (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.4.99.901, module version = 2.2.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.0 (II) Loading sub module "intel_master" (II) LoadModule: "intel_master" (II) Loading /usr/lib/xorg/modules/drivers//intel_master_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.4.99.901, module version = 2.2.99 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.0 And for my comment about not being able to test yet on Gentoo, here is the mesa ebuild changelog: 13 Jun 2008; Donnie Berkholz <dberkholz@gentoo.org>; mesa-7.1_rc1.ebuild: Change libdrm dep to 2.3.1 or newer. It won't actually build for the intel driver yet, but others might work.
*** Bug 9539 has been marked as a duplicate of this bug. ***
Hi, all It seems this isn't an Intel driver issue. These cases all select a visual which hasn't depth attribute to create a GLX rendering context, then attach this context to the current drawable. So subsequent rendering are done without depth test. As for it works fine on Fedora 9, All GLX visuals have depth attribute with xsever(1.5.0 RC 1) by default. If adding *Option "GlxVisuals" "all"* to the ServerLayout section of your xorg.conf, you would get more GLX visuals.
Created attachment 17347 [details] Screenshot-TVTK Scene-1.png Thanks for your help but unfortunately that doesn't fix it for me on xorg-server-1.4.2. Screenshot attached (all the noise is the "back" of the bunny showing through) but looks the same as it did without the 'Options "GlxVisuals" "all"' How can I confirm that that the option did anything at all? $ cat /var/log/Xorg.0.log | grep -i glx | grep -i visual (WW) AIGLX: 3D driver claims to not support visual 0x23 (WW) AIGLX: 3D driver claims to not support visual 0x24 --- 8< --- (WW) AIGLX: 3D driver claims to not support visual 0x31 (WW) AIGLX: 3D driver claims to not support visual 0x32 (I still cannot compile mesa 7.1rc1 to test whether that or xorg-server 1.5rc would help.)
'Options "GlxVisuals" "all"' doesn't work with xorg-server-1.4.2. I mean if you run Xsever 1.5.0 RC 1 with this option, you would get more GLX visuals, some of them don't have depth attribute too. These test cases will select a visual which doesn't have depth attribute and work incorrectly as well. Running Xserver 1.5.0RC1 without this option, all valid visuals have depth attribute, so these test cases always select a visual which has depth attribute. It only respond to comment #4 "Here's the message about it working on Fedora 9".
I see. Thanks for explaining. I will test as soon as mesa 7.1rc1 compiles on gentoo w/ intel. If I understand correctly, this is an application error? (not an X bug) But then why only on intel? It works fine on ati (r200).
(In reply to comment #9) > I see. Thanks for explaining. I will test as soon as mesa 7.1rc1 compiles on > gentoo w/ intel. > > If I understand correctly, this is an application error? (not an X bug) > > But then why only on intel? It works fine on ati (r200). > ati(r200) doesn't support a visual without depth attribute.
haihao: Can you avoid forward duping bugs (unless the later bug has substantially more information)? Bug #9539 was much older (this bug was only opened last month) and this bug doesn't contain much more information than 9539... It seems "fairer" to credit the bug that came first.
(In reply to comment #11) > haihao: > Can you avoid forward duping bugs (unless the later bug has substantially more > information)? Bug #9539 was much older (this bug was only opened last month) > and this bug doesn't contain much more information than 9539... It seems > "fairer" to credit the bug that came first. Hi, Sitsofe Usually, I avoid forward dupping bugs. There are two reasons: One is another bug 16363 has been marked as a dup of this bug. Another is I think some comments here are more useful, so I marked #9539 as a dup of this bug. Thanks Haihao
I've now tried mesa 7.1rc3, but now the examples that were missing an zbuffer just crash: $ cd /usr/lib/python2.5/site-packages/vtk/gtk $ export MESA_DEBUG=1 $ python GtkGLExtVTKRenderWindowInteractor.py GtkGLExtVTKRenderWindowInteractor.py:45: GtkDeprecationWarning: gtk.FALSE is deprecated, use False instead self.set_double_buffered(gtk.FALSE) GtkGLExtVTKRenderWindowInteractor.py:299: GtkDeprecationWarning: gtk.TRUE is deprecated, use True instead window.show() GtkGLExtVTKRenderWindowInteractor.py:300: GtkDeprecationWarning: gtk.mainloop is deprecated, use gtk.main instead gtk.mainloop() The program 'GtkGLExtVTKRenderWindowInteractor.py' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 28 error_code 2 request_code 155 minor_code 3) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) This next example works fine (as it did before): $ cd /usr/lib/python2.5/site-packages/vtk/tk $ export MESA_DEBUG=1 $ python vtkTkRenderWindowInteractor.py Failed to initialize TTM buffer manager. Falling back to classic.
Yeah! Updated to rc6 and latest intel and now this seems to work. xorg-server-1.4.99.906, x11-drivers/xf86-video-intel-2.4.0, mesa-7.1_rc3 (One day before my thesis defense too, so I can have a live demo.)
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.