Re: [Mesa3d-dev] Segfault on glClear of non-existent stencil buffer caused by bd1ce874728c06d08a1f9881f51edbdd2f1c9db0

[Brian P. <br...@vm...>]

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