[Mesa-dev] [PATCH 1/7] mesa: Add field gl_renderbuffer.Unwrapped
Ian Romanick
idr at freedesktop.org
Thu Jun 16 09:27:25 PDT 2011
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
We have future hardware that only does separate depth and stencil.
However, almost every existing application wants to use packed depth /
stencil. Few apps have (tested) fallback paths.
> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk36Lu0ACgkQX1gOwKyEAw9IxQCfU2tWbcb6pSdHw45oEqT6ddhG
L94AoJjrwm1poxo/hpP0LVe/rZjR1gZD
=rDOb
-----END PGP SIGNATURE-----
More information about the mesa-dev
mailing list