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

[Brian Paul]

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.

-Brian