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

Eric Anholt eric at anholt.net
Thu May 3 10:33:32 PDT 2012


On Wed, 02 May 2012 18:32:01 -0700, Chad Versace <chad.versace at linux.intel.com> wrote:
> 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).
> 
> 2. Create separate entry points:
>       - _mesa_BindFramebufferEXT, which implements
>           - glBindFramebufferEXT
>           - glBindFramebufferOES
>           - glBindFramebuffer in GLES2
>       - _mesa_BindFramebufferARB, which implements
>           - glBindFramebufferARB
>           - glBindFramebuffer in GL 3.x

3. Just change this hunk of _msea_BindFramebufferEXT:

      else if (!newDrawFb && ctx->Extensions.ARB_framebuffer_object) {
         /* All FBO IDs must be Gen'd */
         _mesa_error(ctx, GL_INVALID_OPERATION, "glBindFramebuffer(buffer)");
         return;
      }

to just not throw the error if EXT_fbo or if the API is ES2?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120503/25406509/attachment.pgp>


More information about the mesa-dev mailing list