[Mesa-dev] [PATCH 1/2] mesa: Only require Gen'ed name for glBindFramebuffer on desktop

[Chad Versace]

On 12/03/2012 09:15 AM, Ian Romanick wrote:
> On 12/01/2012 12:41 PM, Kenneth Graunke wrote:
>> On 12/01/2012 11:10 AM, Ian Romanick wrote:
>>> From: Ian Romanick <ian.d.romanick at intel.com>
>>>
>>> Desktop OpenGL implementations that support either
>>> GL_ARB_framebuffer_object
>>> or OpenGL 3.0 must require names from glGenFramebuffers for
>>> glBindFramebuffer.  We have enforced this rule for quite some time.
>>> However,
>>> OpenGL ES 1.0, 2.0, and 3.0 implementations are required to allow
>>> user-defined
>>> names (e.g., not from glGenFramebuffers{OES,}).
>>
>> Ugh...seriously?  What were they thinking?  They require Gen'd names for
>> just about everything else in ES 3.0...
> 
> All new object types use the new behavior (requiring Gen'd names). Vertex array
> objects, sampler objects, transformfeedback objects, etc. must use Gen'd names.
> 
> All pre-existing object types continue to have the old behavior (not requiring
> Gen'd names) for backwards compatibility with OpenGL ES 2.0. Textures,
> framebuffer objects, and renderbuffers (which, it now occurs to me, my patch
> misses) can use user-generated names.
> 
>>> The Intel drivers have hacked around this by not enabling
>>> GL_ARB_framebuffer_object in an ES context.  Instead, just pick the
>>> correct
>>> behavior in _mesa_BindFramebuffer based on the context API.
>>
>> This was the whole reason for the EXT/ARB debacle we had?  Over one line
>> of code? :)

Ken, the debacle hasn't ended yet. This one-liner only doesn't fix anything.
It only allows to consistently enable GL_ARB_fbo regardless of API.

The real solution to the debacle requires creating separate entry points for
the glBindFramebufferARB/EXT. But that is soooo low on our priority list now...