On Mon, May 14, 2012 at 4:40 PM, Brian Paul <bri...@vmware.com> wrote: > On 05/12/2012 10:11 AM, Marek Olšák wrote: >> >> It may fail with an unsupported format, but that's not an allowed case >> where >> RenderbufferStorage may fail. > > > I've read your comment several times but I still can't quite understand the > whole issue. > > The intention was that AllocStorage() should never fail because of the > internalFormat value. We do error checking of internalFormat earlier in > renderbuffer_storage(). Then the driver chooses a hw format that best > matches the requested internalFormat.
The driver is r600g and the format is GL_RGB9_E5 (EXT_texture_shared_exponent). There is sampler support, but no colorbuffer support. The format is quite special, no other format matches it well, though I guess any RGB float format would work. However the spec doesn't require renderbuffer support despite the fact the format is accepted in glRenderbufferStorage. The problem is st_choose_renderbuffer_format returns PIPE_FORMAT_NONE, because it looks for GL_RGB9_E5 with PIPE_BIND_RENDER_TARGET support. I don't think we should allocate a renderbuffer if we know the user won't be able to render to it. The other option is to pretend that we allocated something, so that glCheckFramebufferStatus can fail later. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
