[Mesa-dev] Conflicts between OES/EXT/ARB_framebuffer_object and GL3.0/GLES2
brianp at vmware.com
Thu May 3 06:44:40 PDT 2012
On 05/03/2012 04:36 AM, Marek Olšák wrote:
> On Thu, May 3, 2012 at 3:32 AM, Chad Versace
> <chad.versace at linux.intel.com> wrote:
>> (FYI, if I understand the gallium code, the only drivers that currently
>> enable both are Intel, swrast, and OSMesa).
> Gallium also enables both if packed depth-stencil textures are
> supported (which is the case with most, if not all, drivers).
> Otherwise, it only enables the EXT variant.
>> 2. Create separate entry points:
>> - _mesa_BindFramebufferEXT, which implements
>> - glBindFramebufferEXT
>> - glBindFramebufferOES
>> - glBindFramebuffer in GLES2
>> - _mesa_BindFramebufferARB, which implements
>> - glBindFramebufferARB
>> - glBindFramebuffer in GL 3.x
>> Any opinions? (I slightly prefer 2).
> FWIW, 2 seems to be a good plan to me too.
I'd be happy with that too.
BTW, I went and checked the GLX opcodes for the ARB vs. EXT functions.
Most of the entrypoints share the same GLX opcode, like the
glDelete* and glGen* functions. Luckily, the glBind* functions have
different opcodes for EXT vs. ARB.
Back when I first implemented ARB_fbo I layered all the functions on
EXT_fbo because I thought all the GLX opcodes were shared. Maybe that
changed at some point.
Thanks for digging into this, Chad.
More information about the mesa-dev