[Mesa-dev] [PATCH] mesa: initialize renderbuffer fields even if AllocStorage fails

[Brian Paul]

On 05/14/2012 10:44 AM, Marek Olšák wrote:
> On Mon, May 14, 2012 at 4:40 PM, Brian Paul<brianp at 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.

This looks like a spec/documentation issue.  The GL 3.0 spec (page 
180) says GL_RGB9_E5 is a texture-only format.  But the 
GL_EXT_texture_shared_exponent spec says it's accepted by 
glRenderbufferStorage.

I just hacked up a quick test for the NVIDIA driver.  Passing 
GL_RGB9_E5 to glRenderbufferStorage() generates a GL_INVALID_OPERATION 
error.  Mesa will need some changes if we want to generate the same 
error, rather than GL_INVALID_ENUM.

Could you test w/ AMD's driver?


> 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

-Brian