[Mesa-dev] [PATCH 11/20] glapi: Remove static dispatch for functions that didn't exist in fglrx

[Ian Romanick]

On 05/15/2015 12:11 PM, Emil Velikov wrote:
> On 15/05/15 17:29, Ian Romanick wrote:
>> On 05/14/2015 03:01 PM, Emil Velikov wrote:
>>> On 13/05/15 19:44, Ian Romanick wrote:
>>>> From: Ian Romanick <ian.d.romanick at intel.com>
>>>>
>>>> Comparing the output of
>>>>
>>>>     nm -D arch/x86_64/usr/X11R6/lib64/fglrx/fglrx-libGL.so.1.2 |\
>>>>         grep ' T gl[^X]' | sed 's/.* T //'
>>>>
>>>> between Catalyst 14.6 Beta and this commit, the only change is a bunch
>>>> of functions that AMD exports that Mesa does not and some OpenGL ES
>>>> 1.1 functions.
>>>>
>>>> The OpenGL ES 1.1 functions (e.g., glAlphaFuncx) are added by extensions
>>>> in desktop.  Our infrastructure doesn't allow us to statically export a
>>>> function in one lib and not in another.  The GLES1 conformance tests
>>>> expect to be able to link with these functions, so we have to export
>>>> them.
>>>>
>>> Iirc the Catalyst driver has some (unofficial ?) support for EGL/GLES
>>> via symlinking the libs to libGL. I'm assuming that is the reason which
>>> "inspired" their library to export those symbols. Imho there is no
>>> reason to even remotely worry about them.
>>
>> It's the other way around (which I can make more clear in the commit
>> message).  Mesa still exports the "x" functions, but Catalyst does not.
>>  Due to limitations in our infrastructure, if I disable those functions
>> in libGL they also disappear from libGLESv1_CM.  The Khronos GLES1
>> conformance tests expect libGLESv1_CM to export the "x" functions, so we
>> can't remove them... from either library.
>>
> I guess I wasn't clear enough - the Catalyst does provide a bunch of
> symbols more than mesa. Some of which I assume (although haven't
> checked) are part of the GLES* api. There is something funny especially
> since the same library provides eglGetProcAddress.
> 
> There are some (rather strange) suggestions on the web that the library
> can be used as a libEGL/libGLES* replacement.
> 
> Thus I aimed my earlier comment as - there is not point for mesa to
> attempt to provide all the functions listed by the Catalyst.

Ah, okay.  There is a quite large pile of functions that Catalyst
exposes that Mesa does not (like glAddSwapHintRectWIN and
glBeginVertexShaderEXT), but I didn't notice any that looked like GLES
functions. *shrug*

> Hope ^^ came out less patronising than usual :-)
> 
> Cheers,
> Emil
>