[Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2

[Ian Romanick]

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 [1] 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.
>
> [1] 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
>          glGenFramebuffers.
>      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
>      DeleteFramebuffers.
>
>
> 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:
>      glGenFramebuffers(1,&fb);
>      glBindFramebuffer(GL_FRAMEBUFFER, fb);
>      // render render render...
>      glDeleteFramebuffers(1,&fb);
>      // 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. 
See src/mesa/main/arrayobj.c.

> 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?