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

[Brian Paul]

On 05/17/2012 07:20 AM, Marek Olšák wrote:
> 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.

Do you want to implement this change or should I?

-Brian