[Mesa-dev] [PATCH] Fix for dispatch table entries and es2-compatibility mode

[Ian Romanick]

Please don't reply off list.  Subscribe to the list and participate.  We 
can't make decisions that affect everyone behind closed doors.

On 03/13/2013 02:32 AM, Zawistowski, Bartosz L wrote:
> Hi Ian,
>
> Thank you for quick feedback. This fix is aimed at separating EXT and
> ARB framebuffer_object extensions. According to GL spec entry points
> of these two extensions need to have different implementations. There
> is no such distinction now in DRI drivers nor in glapi interface.
> This patch allows other DRI drivers (not delivered with mesa) that
> use glapi to take advantage of both extensions. In order to satisfy
> compilation of mesa DRI drivers, name wrappers have been provided for
> new api calls.

We've had some discussion about this on the mesa-dev list before.  You 
should search the archives.  I believe the only functions that are 
different are glBindRenderbuffer and glBindFramebuffer.  All of the 
other functions have the same GLX protocol opcode, so they are 
indistinguishable in indirect rendering.

Splitting functions other than glBind{Frame,Render}buffer is definitely 
wrong.

> Could you please provide more details regarding compatibility issues
> between libGL and existing DRI drivers you have mentioned?

The driver asks libGL where various functions belong in the dispatch 
table.  Right now, drivers only ask for one of the names and assume all 
variations will go through the same dispatch entry.  With this change, 
existing driver binaries won't set the dispatch pointer for 
glBindFramebuffer (only for glBindFramebufferEXT), for example.

Since the same mechanism is used inside the xserver, changing the 
drivers would also require changes in the server's GLX code.

What we have done is implement the ARB behavior for both versions.  If 
you ask 100 developers what the difference is, I would bet at least 97 
respond, "There's a difference?" :)  And the other 3 will wonder what 
the point of using non-Gen names is.

In short... Yes, there's a bug, but fixing it makes things worse for 
very little, if any, actual benefit.

The bigger thing to worry about is that glBindFramebuffer in OpenGL ES 
2.0 (and 3.0) behaves different from glBindFramebuffer in desktop OpenGL 
3.0.  Since you know which API was used to create the context, just 
select the behavior in the implementation of glBindFramebuffer based on 
the API.