-----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----- _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev