Bug 90162

Summary:	glGetFramebufferAttachmentParameteriv failing if certain FB attributes are zero
Product:	Mesa	Reporter:	Martina Kollarova <martina.kollarova>
Component:	GLX	Assignee:	Tapani Pälli <lemody>
Status:	RESOLVED NOTABUG	QA Contact:	mesa-dev
Severity:	normal
Priority:	medium
Version:	10.1
Hardware:	Other
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	reproducer.output glxinfo.output fix for invalid enum issue

Description Martina Kollarova 2015-04-24 11:40:24 UTC

Created attachment 115302 [details]
reproducer.output

The command
glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_DEPTH, GL_FRAMEBUFFER_ATTACHMENT_DEPTH_SIZE, &depth_bits)
fails with GL_INVALID_OPERATION if the attribute GLX_DEPTH_SIZE is set to 0 (or not explicitly set) in the FB config.

The same happens with the command
glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_STENCIL, GL_FRAMEBUFFER_ATTACHMENT_STENCIL_SIZE, &stencil_bits)
if GLX_STENCIL_SIZE is set to 0 or not explicitly set.

You can reproduce those two cases with
https://github.com/mkollaro/opengl_snippets/blob/getattachments/glx/main.cpp (after building, run with `./build/bin/glx`). My output is in the attachments as `reproducer.output`.

Additionally, if GLX_DOUBLEBUFFER is set to false, the command
glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_BACK_LEFT, GL_FRAMEBUFFER_ATTACHMENT_ALPHA_SIZE, &alpha_bits);
also fails with GL_INVALID_OPERATION, but not if set to true. This error happened to me in the Chromium project, but I cannot reproduce it in the above mentioned code, because I somehow cannot get a context with GLX_DOUBLEBUFFER set to false (this is probably just my mistake).

I would expect this command to return zero if e.g. the depth size is set to zero, or at least use some more informative error message, since the command is correct and only the framebuffer configuration is wrong.

My system is Linux Mint 17.1 Rebecca, more info in the glxinfo.output attachment.

lspci -vnn|grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA controller])
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:13d8] (rev a1) (prog-if 00 [VGA controller])

Comment 1 Martina Kollarova 2015-04-24 11:41:29 UTC

Created attachment 115303 [details]
glxinfo.output

Comment 2 Tapani Pälli 2015-05-12 05:50:18 UTC

I'm not able to reproduce this (tested using Mesa 10.6 and 10.4.7).

I noticed from your glxinfo.output that you are using quite old version, Mesa 10.1.3. Could you test with more recent version?

Comment 3 Martina Kollarova 2015-05-12 10:50:05 UTC

I reproduced it with Mesa 10.6.0-devel (git-971be2b 2015-05-12 trusty-oibaf-ppa). I got the drivers from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

Comment 4 Tapani Pälli 2015-05-12 11:41:45 UTC

(In reply to Martina Kollarova from comment #3)
> I reproduced it with Mesa 10.6.0-devel (git-971be2b 2015-05-12
> trusty-oibaf-ppa). I got the drivers from
> https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

And so did I, I was simply using wrong branch of your github repo. Thanks, will take a look what's wrong.

Comment 5 Tapani Pälli 2015-05-13 06:31:48 UTC

These errors are according to the spec and happen because of following reason.

---- 8< ----
    OpenGL 4.0 Compatibility, page 449:
    
    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.
---- 8< ----

In the application before all other queries, you'll need to query for attachment object type:

    glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT,
        GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, &type);

If type is GL_NONE, then other queries should not be made. Please resolve as NOTABUG if you agree with this.

Comment 6 Tapani Pälli 2015-05-13 07:07:49 UTC

Having said that, I noticed that glGetFramebufferAttachmentParameteriv is broken if you try to query type or name of non-existing attachment point (for desktop GL). But that should be another bug.

Comment 7 Martina Kollarova 2015-05-13 08:05:12 UTC

>    glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT,
>        GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, &type);

This query generated a GL_INVALID_ENUM for me.

Comment 8 Tapani Pälli 2015-05-13 08:56:51 UTC

(In reply to Martina Kollarova from comment #7)
> >    glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT,
> >        GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, &type);
> 
> This query generated a GL_INVALID_ENUM for me.

Yep, like stated in comment #6, that seems to be broken. I'm attaching here a patch to make it work in case you have Mesa from git repository to try. I will send this patch later to mesa-dev after some careful spec investigation and testing.

Comment 9 Tapani Pälli 2015-05-13 08:57:48 UTC

Created attachment 115736 [details] [review]
fix for invalid enum issue

This helps in getting GL_NONE as object type when there is no attachment in given attachment point.

Comment 10 Tapani Pälli 2015-07-04 05:47:27 UTC

I'm resolving this as per comment #5

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.