On Wed, 2009-01-14 at 15:52 -0800, Brian Paul wrote: > An extra wrinkle is the situation where the user allocates a 16bpp depth > texture or renderbuffer then tries to render to it along with a stencil > buffer. We'd have to promote the 16bpp Z values to 24-bit Z values and > mix in the stencil values to setup the depth/stencil renderbuffer.
There's no wrinkle there at all. The user has selected a combination that, while technically valid, the hardware cannot do. The FBO fails the completion test with the error GL_FRAMEBUFFER_UNSUPPORTED. We (the ARB) put that error in to handle exactly this case. The i965 driver was not right before, and the new behavior isn't right either. I believe that we should: - Return 24-bit depth for texture or renderbuffer unless the application specifically asks for GL_DEPTH_COMPONENT16. intel_alloc_renderbuffer_storage already does this for renderbuffers. However, intelChooseTextureFormat needs some changes. - If the application tries to attach a GL_DEPTH_COMPONENT16 texture (or renderbuffer) with a stencil buffer, fail the completion test with GL_FRAMEBUFFER_UNSUPPORTED. I see a couple problems in the existing Mesa code, but I might be overlooking something. I don't see a way for the driver to generate failures in CheckFramebufferCompletion. I also don't see how the driver disables rendering when an incomplete FBO is bound.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
