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

[Marek Olšák]

On Mon, May 14, 2012 at 6:59 PM, Brian Paul <brianp at vmware.com> wrote:
> 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 AMD driver also generates GL_INVALID_OPERATION.

Marek