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.roman...@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...
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
