[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