[Mesa-dev] [PATCH v2] mesa/main: Fix FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for NONE attachment type

Alejandro Piñeiro apinheiro at igalia.com
Thu Jan 19 10:57:28 UTC 2017


On 19/01/17 05:33, Iago Toral wrote:
> On Wed, 2017-01-18 at 16:48 -0200, Alejandro Piñeiro wrote:
>> When the attachment type is NONE (att->Type),
>> FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE should be NONE too.
>>
>> Note that technically, the current behaviour follows the spec. From
>> OpenGL 4.5 spec, Section 9.2.3 "Framebuffer Object Queries":
>>
>>    "If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then
>>     either no framebuffer is bound to target; or the default
>>     framebuffer is bound, attachment is DEPTH or STENCIL, and the
>>     number of depth or stencil bits, respectively, is zero."
>>
>> Reading literally this paragraph, for the default framebuffer, NONE
>> should be only returned if attachment is DEPTH and STENCIL without
>> being allocated.
>>
>> But it doesn't makes too much sense to return DEFAULT_FRAMEBUFFER if
>> the attachment type is NONE. For example, this can happens if the
>> attachment is FRONT_RIGHT run on monoscopic mode, as that attachment
>> is only available on stereo mode.
>>
>> With the current behaviour, defensive querying of the object type
>> would not work properly. So you could query the object type checking
>> for NONE, get DEFAULT_FRAMEBUFFER, and then get and INVALID_OPERATION
>> when requesting other pnames (like RED_SIZE), as the real attachment
>> type is NONE.
>>
>> This fixes:
>> GL45-CTS.direct_state_access.framebuffers_get_attachment_parameters
>>
>> v2: don't change the behaviour when att->Type != GL_NONE, as caused
>>     some ES CTS regressions
>> ---
>>
>> The purpose of the patch was ensuring that OBJECT_TYPE is NONE if the
>> saved attachment type (att->Type) is NONE. But v1 changed the
>> behaviour on some cases, where att->Type != NONE, creating
>> regressions
>> on the following tests:
>>
>> ES3-
>> CTS.functional.state_query.fbo.read_framebuffer_default_framebuffer
>>   ES3-
>> CTS.functional.state_query.fbo.draw_framebuffer_default_framebuffer
>>
>> v2 makes the condition somewhat harder to understand, and includes
>> two
>> atty->Type != GL_NONE checks. I was not able to find something more
>> simple and shorter. A more simple and easy to read check would be:
>>
>>       if (att->Type == GL_NONE)
>>          *params = GL_NONE;
>>       else
>>          *params = (_mesa_is_winsys_fbo(buffer) &&
>>                     ((attachment != GL_DEPTH && attachment !=
>> GL_STENCIL) ||
>>                      (att->Type != GL_NONE)))
>                        ^^^^^^^^^^^^^^^^^^^^^^
> Here we already know that att->Type != GL_NONE is true, so this part of
> the condition does not add anything, right?

Well, when I was working on this patch, I also tried that alternative,
so as it keep failing I though that I was doing something wrong. In any
case, while writing your answer I realized that perhaps the error is on
the test that regresses (see below).

>  In that case we could
> simplify this to:
>
> if (att->Type == GL_NONE)
>    *params = GL_NONE;
> else
>    *params = _mesa_is_winsys_fbo(buffer) &&
>               attachment != GL_DEPTH && attachment != GL_STENCIL
>                  ? GL_FRAMEBUFFER_DEFAULT : att->Type;

Doing this we get a regression on the following test:
ES3-CTS.functional.state_query.fbo.read_framebuffer_default_framebuffer

That is failing on the following case:
  * framebuffer is default framebuffer
  * attachment is GL_DEPTH (also with GL_STENCIL)
  * att->Type is GL_RENDERBUFFER.

The test expect default framebuffer, but it gets RENDERBUFFER. But I
don't see anything on the spec forcing to return DEFAULT_FRAMEBUFFER for
that case.

> If this fixes the problem, I'd go with this version instead, as I find
> it a lot easier to understand.

I agree that is easier to understand. I will investigate a little more
the test, to check if the regression is bogus.

>
>>             ? GL_FRAMEBUFFER_DEFAULT : att->Type;
>>
>> But seems somewhat verbose.
>>
>>
>>  src/mesa/main/fbobject.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
>> index 044bd63..eee0b99 100644
>> --- a/src/mesa/main/fbobject.c
>> +++ b/src/mesa/main/fbobject.c
>> @@ -3757,7 +3757,8 @@
>> _mesa_get_framebuffer_attachment_parameter(struct gl_context *ctx,
>>         */
>>        *params = (_mesa_is_winsys_fbo(buffer) &&
>>                   ((attachment != GL_DEPTH && attachment !=
>> GL_STENCIL) ||
>> -                  (att->Type != GL_NONE)))
>> +                  (att->Type != GL_NONE))) &&
>> +         att->Type != GL_NONE
>>           ? GL_FRAMEBUFFER_DEFAULT : att->Type;
>>        return;
>>     case GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT:




More information about the mesa-dev mailing list