On Wed, Mar 24, 2010 at 12:56 AM, Brian Paul 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_c
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_stenc
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_FORM
We have a visual haveStencilBuffer == 1 but stencilBits == 0 (and no
stencil renderbuffer), which I suppose shouldn't be happening.
visualid and fbconfigid are also 0.
Here is the full structure:
$1 = {next = 0x0, rgbMode = 1 '\001', floatMode = 0 '\000',
colorIndexMode = 0 '\000', doubleBufferMod
Luca Barbieri wrote:
> Apparently _mesa_Clear should not set BUFFER_BIT_STENCIL if the visual
> lacks a stencil buffer.
>
> So it seems the visual is somehow incorrect, or a visual with a
> stencil buffer is being selected but the stencil renderbuffer is not
> actually set.
At line 167 of src/mes
Apparently _mesa_Clear should not set BUFFER_BIT_STENCIL if the visual
lacks a stencil buffer.
So it seems the visual is somehow incorrect, or a visual with a
stencil buffer is being selected but the stencil renderbuffer is not
actually set.
---
Commit bd1ce874728c06d08a1f9881f51edbdd2f1c9db0 "st/dri: Switch from
st_public.h to st_api.h" broke etracer on Gallium nvfx.
The root cause appears to be that etracer calls glClear with the
stencil bit set, but does not ask for a stencil buffer.
Enabling "stencil_buffer" in the etracer config work
