[Mesa-dev] [PATCH 1/6] mesa: Add field gl_renderbuffer.Unwrapped

[Alex Deucher]

On Thu, Jun 16, 2011 at 1:26 PM, Chad Versace <chad at chad-versace.us> wrote:
> On 06/16/2011 08:01 AM, Alex Deucher wrote:
>> On Wed, Jun 15, 2011 at 9:09 PM, Chad Versace <chad at chad-versace.us> wrote:
>>> If a renderbuffer wraps multiple renderbuffers, then Unwrapped points to
>>> the them.
>>>
>>> For example, if hardware requires separate depth and stencil buffers
>>> (X8_Z24 and S8), then glRenderbufferStorage(GL_DEPTH24_STENCIL8) may
>>> create a fake S8_Z24 renderbuffer for which Unwrapped[BUFFER_DEPTH] and
>>> Unwrapped[BUFFER_STENCIL] point to the real X8_Z24 and S8 renderbuffers.
>>>
>>
>> FWIW, evergreen and newer chips only support separate stencil and
>> depth, so we had a similar issue.  We ended up using
>> GL_ARB_shader_stencil_export to implement writes to the stencil.
>> Start of the thread:
>> http://lists.freedesktop.org/archives/mesa-dev/2010-September/003318.html
>>
>> Alex
>
> The thread mentions some strange behaviour on r600:
>> so on r600g, the only way to directly write to the stencil is via the
>> shader, using a transfer would require an extra step to flush the DS
>> buffer
>
> I've observed mysterious behaviour when writing to intel's stencil buffer through a memory mapped pointer. It's seems that the
> hardware fails to recognize that the writes ever occurred. (Writes via rendering work fine).  I still need to investigate the
> problem further, but perhaps GL_ARB_shader_stencil_export is what the intel driver needs to work around this problem.
>
> Thanks for pointing this out.
>

I suspect the hardware stores the depth or stencil in some compressed
format.  On radeon, you have to do a special  uncompress operation
(either a blit or in place depending on what you want to do) if you
want to use the depth or stencil buffer as a texture or render target.

Alex

> --
> Chad Versace
> chad at chad-versace.us
>