Ian Romanick wrote: > 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.
Yeah, I'm taking some shortcuts for the time being in order to get some things running. I'll be spending more time on this, and probably doing GL_ARB_framebuffer_object too... -Brian ------------------------------------------------------------------------------ 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
