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

Chad Versace chad at chad-versace.us
Thu Jun 16 10:47:21 PDT 2011


On 06/16/2011 07:14 AM, Brian Paul wrote:
> On 06/15/2011 06:34 PM, Chad Versace 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.
>>
>> Alter the following function to take Unwrapped into account:
>>      _mesa_framebuffer_renderbuffer
>>      _mesa_update_depth_buffer
>>      _mesa_update_stencil_buffer
>>      _mesa_reference_renderbuffer
> 
> Chad, could you give a bit of background on the big picture here? When/why do we need to represent separate depth and stencil
> buffers as a unified depth+stencil buffer?

Like Ian said, we have future hardware that requires a separate stencil buffer. But we still need to accomodate apps that use
renderbuffers with format GL_DEPTH_STENCIL.

> I'd like to move away from the whole renderbuffer/wrapper business. As I mentioned the other day, I'd like to move to a simple
> map/unmap model to accesss renderbuffer (and texture) data.  Mesa would generally see the buffers as-is without any kind of
> wrappers/converters.  If a driver needed to change the appearance of buffer(s) to core Mesa, it would have to do the data
> munging inside map()/unmap().  Would that approach work with the problem you're solving with unwrappers?
> 
> Thanks.
> 
> -Brian

I think the problems I'm solving are tractable within that approach. The solution would involve defing custom renderbuffer
accessors (GetRow, PutRow) for the fake S8_Z24 buffer. I'll give that a try today and see how it works.

-- 
Chad Versace
chad at chad-versace.us


More information about the mesa-dev mailing list