Menu
▾
▴
Re: [Mesa3d-users] Intel driver depth buffer
|
From: Brian P. <bri...@tu...> - 2007-12-03 18:53:52
|
Peter Clifton wrote: > On Fri, 2007-11-30 at 15:02 -0700, Brian Paul wrote: >> Peter Clifton wrote: >>> Hi, >>> >>> I'm having some strange (seemingly) depth buffer related issues running >>> VTK. >>> >>> I've got the Intel X driver version 2.1.0 (+ Ubuntu Gutsy patches), and >>> mesa version 7.0.1 (Ubuntu Gutsy - might have some patching). >>> >>> When I run a simple test program: >>> >>> MESA_DEBUG=1 ipython -wthread vtk_test.py >>> >>> Where vtk_test.py is from the first example here: >>> http://scipy.org/Cookbook/MayaVi/mlab >>> >>> I get this warning: >>> Mesa warning: glEnable(GL_DEPTH_TEST) but no depth buffer >> It means your window wasn't created with a Z/depth buffer, but the >> program is trying to enable/use depth buffering. > > I've got that far poking through sources, but it didn't help me fix it > yet! > >> My guess is there's a bug somewhere in the python code related to GL and >> window creation. > > The visual seems to be chosen with: > > glXChooseVisual( dpy, DefaultScreen(dpy), attribList ) > > I've not got to rebuilding wx widgets with debug printf to verify what > this returns, but its probably my next step in trying to understand the > issue. > > Only in the case where stereo is explicitly requested, does the VTK > viewer explicitly ask for a depth buffer, normally a default attribList > is made. (Although reading around the code, it seems the default is to > request a >1 bit depth buffer). > > I've tried explicitly setting a requirement for a 16 / 32 bit Z buffer, > and it didn't seem to help. If you could examine the XVisualInfo returned by glXChooseVisual you could determine which visual ID is being used, then compare it to the output of glxinfo to see if you're really getting a depth buffer. >> Do other OpenGL apps (or demos like glxglears) seem OK? > > They seem fine, although glxgears isn't a good test for depth surely, > being flat? Flat shading? That's unrelated to depth testing. You can use the cursor/arrow keys to rotate the gears to be sure depth testing is working. > Other apps seem OK, so its probably Wx's / wxPython's fault, > as you say. > > glxinfo reports plenty of depth-buffer capable visuals: > visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat > ---------------------------------------------------------------------- > 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow > 0x28 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow > 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x2b 24 dc 0 32 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None > 0x2d 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > 0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow > 0x30 24 dc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 Slow > 0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x32 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow > 0x56 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon > > The one thing which is odd, is the Xorg.0.log file has: > > (WW) AIGLX: 3D driver claims to not support visual 0x23 > (WW) AIGLX: 3D driver claims to not support visual 0x24 > (WW) AIGLX: 3D driver claims to not support visual 0x25 > (WW) AIGLX: 3D driver claims to not support visual 0x26 > (WW) AIGLX: 3D driver claims to not support visual 0x27 > (WW) AIGLX: 3D driver claims to not support visual 0x28 > (WW) AIGLX: 3D driver claims to not support visual 0x29 > (WW) AIGLX: 3D driver claims to not support visual 0x2a > (WW) AIGLX: 3D driver claims to not support visual 0x2b > (WW) AIGLX: 3D driver claims to not support visual 0x2c > (WW) AIGLX: 3D driver claims to not support visual 0x2d > (WW) AIGLX: 3D driver claims to not support visual 0x2e > (WW) AIGLX: 3D driver claims to not support visual 0x2f > (WW) AIGLX: 3D driver claims to not support visual 0x30 > (WW) AIGLX: 3D driver claims to not support visual 0x31 > (WW) AIGLX: 3D driver claims to not support visual 0x32 > > Which would leave only visual 0x56, which has no depth buffer. > (What is Caveat: Ncon?) Are these warnings just spurious, or do I have > config problem which might relate to the Z-Buffer issue? That indicates your libGL, dri driver, and/or X server are at different versions. If other GL apps seem OK, then you can probably ignore the warnings. > I remember looking up these warnings before, but not finding much > conclusive about their cause / severity. -Brian |
