[Mesa-dev] [PATCH 4/4] mesa: stop aliasing ARB and core shader API functions

[Jose Fonseca]

----- Original Message -----
> On 03/10/2014 02:52 PM, Jose Fonseca wrote:
> > 
> > 
> > ----- Original Message -----
> >> On 03/10/2014 03:09 PM, Ian Romanick wrote:
> >>> On 03/10/2014 02:06 PM, Ian Romanick wrote:
> >>>> No way.  This will break existing applications on Linux.
> >>
> >> How so?  Before, for example, we had glCompileShaderARB(GLhandleARB) and
> >> glCompileShader(GLuint) libGL entrypoints and GLhandleARB=GLuint.  After
> >> these changes it's the same story.  No change.
> >>
> >>
> >>> This also breaks the libGL <-> DRI driver ABI.  These function entry
> >>> points have been aliased for... a decade?  I can't understand why we'd
> >>> break our own ABI because of something silly that Apple did.  This feels
> >>> like madness.
> >>
> >> Hmm, I forgot about the libGL / DRI ABI.  Crap.  I guess it's the case
> >> of using a new libGL with an old DRI driver that would break.  Have we
> >> even been testing ABI interoperability lately?  I'm not sure how
> >> libglapi factors into this either.
> > 
> > I'm not sure how the libGL<->DRI ABI is preserved with
> > src/mapi/glapi/gen/gl_API.xml edits.  If it's a matter of not touching
> > earlier entrypoints, then the solution should be to move the new
> > entrypoints (e.g., ShaderSourceARB) to the bottom of the gl_API.xml with a
> > high offset, so that it gets added to the end of the table.
> 
> The problem is that drivers are built expecting that glCompileShader and
> glCompileShaerARB are the same function.  As a result, the driver only
> asks libGL the offset of one of those functions in the dispatch table,
> and it only sets one pointer in the dispatch table.  Then an application
> tries to call the "other" function, gets a NULL dispatch pointer, and
> explodes.
>
> The inverse problem exists with an old libGL and a new built driver.  In
> that case the driver will ask for two different offsets, but libGL will
> only give it one.

I see.

BTW, this means that aliasing in the dispatch API was a design mistake, as it is irreversible in face of this bi-directional backward compatibility requirement -- once two functions are aliased, they need to be aliased for eternity.  Even if turns out there was a bad interpretation of the spec, or a new extension comes along and adds conflicting semantics to one of the aliased functions.  It would had been better for entrypoint to have a separate entry in the dispatch table, even if two entries end up pointing to the same function. And we should consider correcting that if/when we need to break compatability for some other reason.

And this happened precisely with ARB_framebuffer_object and EXT_framebuffer_object, change 9f07ca11c1797ac12de1e1c6aef13cf58824b5f5.

Jose