when the value of GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is GL_NONE, querying pname GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME should return zero. Currently GL_INVALID_ENUM is generated.
Created attachment 39558 [details] [review] proposed fix/patch Can you test the attached patch?
Mesa is correct in generating GL_INVALID_ENUM when the object type is not one of GL_TEXTURE or GL_RENDERBUFFER. The GL_ARB_framebuffer_objects spec says: "If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is RENDERBUFFER, then ... If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is TEXTURE, then ... Otherwise, an INVALID_ENUM error is generated."
I looked at the GL_ARB_fbo spec too, but the GL 3.3 spec says (page 276): """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. """ Though I guess since we don't yet support GL 3.3 the code is OK as-is.
(In reply to comment #3) > I looked at the GL_ARB_fbo spec too, but the GL 3.3 spec says (page 276): > > """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. > """ > > Though I guess since we don't yet support GL 3.3 the code is OK as-is. ARG! The same language is in the 3.0 spec, and GL_ARB_framebuffer_objects is supposed to match 3.0. It seems we've found a spec bug. I've submitted a bug against the GL_ARB_framebuffer_objects spec. I've also added piglit test fbo-getframebufferattachmentparameter-01 the reproduces this bug and another similar bug.
(In reply to comment #1) > Created an attachment (id=39558) [details] > proposed fix/patch > > Can you test the attached patch? Tested, the fix works for me.
I've committed the previously attached patch. The fbo-getframebufferattachmentparameter-01 test does not pass yet but Mesa fails in the same way as NVIDIA's driver.
Closing because the fix has been committed.
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.