[Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
idr at freedesktop.org
Thu May 3 08:42:24 PDT 2012
On 05/02/2012 06:32 PM, Chad Versace wrote:
> Mesa has problems in the way it implements glBindFramebuffer and
> glBindFramebufferEXT due to both being implemented by an overloaded
> _mesa_BindFramebufferEXT. This problem causes an Android app  to crash,
> and I want your opinion on how we should fix it.
> The problem is that in the five specs in the subject line, the specified
> behavior of glBindFramebuffer falls into two incompatible categories.
> Mesa implements the wrong behavior for OES_fbo, EXT_fbo, and GLES2 when
> ARB_fbo is internally enabled.
>  Pauli and Charles (CC'd) have more details about this crash, including an
> apitrace, if you're curious.
> Behavior in Category A: ARB_fbo and GL3.0
> The behavior in these specs can be summarized as:
> 1a. glBindFramebuffer may be called only on fb names produced by
> 2a. glBindFramebuffer may not be called on an fb name previously deleted
> with glDeleteFramebuffers.
> Below is the pertinent quote from the ARB_fbo spec. The language in the GL 3.0
> spec is nearly identical.
> A framebuffer object is created by binding
> a name returned by GenFramebuffers (see below) to
> DRAW_FRAMEBUFFER or READ_FRAMEBUFFER. The binding is
> effected by calling
> void BindFramebuffer(enum target, uint framebuffer);
> BindFramebuffer fails and an INVALID_OPERATION error is generated if
> <framebuffer> is not zero or a name returned from a previous call to
> GenFramebuffers, or if such a name has since been deleted with
> Behavior in Category B: EXT/OES_fbo and GLES2
> The behavior in these specs can be summarized as below. This behavior is
> incompatible with points 1a and 2a.
> 1b. glBindFramebuffer may be called on any unused fb name.
> 2b. glBindFramebuffers may be called on an fb name previously deleted with
> glDeleteFramebuffers because, according to these specs, deletion marks
> a name as unused.
> Below is the pertininent quote from the EXT_fbo spec. The language of the GLES
> 2 spec is nearly identical, but without the EXT suffix. The OES_fbo spec
> refers to the EXT_fbo spec.
> The namespace for framebuffer objects is the unsigned integers, with
> zero reserved by the GL to refer to the default framebuffer. A
> framebuffer object is created by binding an unused name to the
> target FRAMEBUFFER_EXT. The binding is effected by calling
> void BindFramebufferEXT(enum target, uint framebuffer);
> Framebuffer objects are deleted by calling
> void DeleteFramebuffersEXT(sizei n, uint *framebuffers);
> <framebuffers> contains<n> names of framebuffer objects to be
> deleted. After a framebuffer object is deleted, [...],
> and its name is again unused.
> The Crashing App
> We have an Android app that does this:
> glBindFramebuffer(GL_FRAMEBUFFER, fb);
> // render render render...
> // go do other stuff...
> glBindFramebuffer(GL_FRAMEBUFFER, fb);
> // This bind unexpectedly failed, and the app panics.
So... the app is expecting this to create a "fresh" FBO?
> The call to glBindFramebuffer fails because, in GLES1 and GLES2 contexts, the
> Intel drivers internally enables both ARB_fbo and EXT_fbo. In
> _mesa_BindFramebufferEXT, the ARB_fbo behavior wins.
> Solutions for core Mesa
> As for fixing _mesa_BindFramebufferEXT, I have two ideas.
> 1. Enforce in _mesa_BindFramebufferEXT that no more than one of ARB_fbo
> and EXT_fbo is enabled, then clean up its validation logic. This is
> a big hammer, and, if done right, can eliminate any ambiguities in behavior.
> (FYI, if I understand the gallium code, the only drivers that currently
> enable both are Intel, swrast, and OSMesa).
I'm not a fan of this. We only redact functionality that don't believe
anyone uses. I'm fairly sure there are still apps that will use EXT_fbo.
> 2. Create separate entry points:
> - _mesa_BindFramebufferEXT, which implements
> - glBindFramebufferEXT
> - glBindFramebufferOES
> - glBindFramebuffer in GLES2
> - _mesa_BindFramebufferARB, which implements
> - glBindFramebufferARB
> - glBindFramebuffer in GL 3.x
This is my preference. I believe vertex array objects work like this.
> Any opinions? (I slightly prefer 2).
> Quick Solution for the Intel drivers
> A quick solution may be as simple as removing ARB_fbo from the Intel drivers'
> GLES1/2 extension lists.
> Do you see any problem in doing this?
> Charles, you have experimented with disabling ARB_fbo from GLES1/2 contexts.
> Did you observe any negative consequences?
More information about the mesa-dev