[Piglit] [PATCH] fbo-getframebufferattachmentparameter-01: fix DEPTH_SIZE query

[Marek Olšák]

I have read the spec carefully and committed a proper fix in piglit.

FYI, I have sent a patch to mesa-dev to fix the same problem in Mesa.

Marek

On Tue, May 31, 2011 at 6:07 PM, Brian Paul <brianp at vmware.com> wrote:
> On 05/30/2011 01:14 PM, Chad Versace wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 05/30/2011 02:14 AM, Marek Olšák wrote:
>>>
>>> Mesa returns 0. It seems correct to me.
>>> ---
>>>  .../fbo/fbo-getframebufferattachmentparameter-01.c |    5 +++--
>>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tests/fbo/fbo-getframebufferattachmentparameter-01.c
>>> b/tests/fbo/fbo-getframebufferattachmentparameter-01.c
>>> index 551a03d..b813b51 100644
>>> --- a/tests/fbo/fbo-getframebufferattachmentparameter-01.c
>>> +++ b/tests/fbo/fbo-getframebufferattachmentparameter-01.c
>>> @@ -148,8 +148,9 @@ piglit_init(int argc, char **argv)
>>>        pass = try_GetAttachmentParam(GL_DEPTH_ATTACHMENT,
>>>
>>>  GL_FRAMEBUFFER_ATTACHMENT_DEPTH_SIZE,
>>>                                      0,
>>> -                                     GL_INVALID_ENUM,
>>> -                                     "")
>>> +                                     0,
>>> +                                     "Expected depth size of depth
>>> attachment to be "
>>> +                                     "%d, got %d instead.\n")
>>>                &&  pass;
>>>
>>>        piglit_report_result(pass ? PIGLIT_PASS : PIGLIT_FAIL);
>>
>> It looks like the test *and* Mesa is wrong. The spec says
>> GL_INVALID_OPERATION should be raised.
>>
>> - From section 6.1.12 "Framebuffer Object Queries" of the OpenGL 3.3 spec:
>>     Upon successful return from GetFramebufferAttachmentParameteriv, if
>>     pname is FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, then param will contain
>>     one of NONE, FRAMEBUFFER_DEFAULT, TEXTURE, or RENDERBUFFER, [...].
>>
>>     If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, no
>>     framebuffer is bound to target. In this case querying pname
>>     FRAMEBUFFER_ATTACHMENT_OBJECT_NAME will return zero, and all other
>>     queries will generate an INVALID_OPERATION error.
>
> Is that from the EXT spec, the ARB spec or the 3.0 spec?  I seem to recall
> there was some inconsistency in some error conditions between those
> variants.
>
> -Brian
>