Luca Barbieri wrote: > The problem seems to be in st_manager.c: > if (visual->depth_stencil_format != PIPE_FORMAT_NONE) { > mode->haveDepthBuffer = GL_TRUE; > mode->haveStencilBuffer = GL_TRUE; > > mode->depthBits = > util_format_get_component_bits(visual->depth_stencil_format, > UTIL_FORMAT_COLORSPACE_ZS, 0); > mode->stencilBits = > util_format_get_component_bits(visual->depth_stencil_format, > UTIL_FORMAT_COLORSPACE_ZS, 1); > } > > This sets haveStencilBuffer even for depth-only buffers. > > How about fixing this to set haveDepthBuffer and haveStencilBuffer > only if bits > 0, and later removing haveStencilBuffer, > haveDepthBuffer and haveAccumBuffer in favor of just testing the *bits > counterparts?
The haveDepth/Stencil fields come from the original SGI GLX. We should probably just test the number of bits in Mesa, as you say. Want to make a patch for that? > BTW, what if we have a floating-point depth buffer, or, say, a shared > exponent floating-point color buffer? How do we represent that with > the visual structure? Those things came along after the SGI GLX release. They'd have to be added to __GLcontextModes. > Shouldn't we be using the actual formats instead of this *bits stuff, > maybe by having Mesa look at its internal structures instead of a > GLXVisual-like struct? yeah, probably. I'd have to study it for a while. -Brian ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev