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

[Ian Romanick]

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.

> Jose
> 
>> -Brian