[Mesa-dev] [PATCH 1/3] glx: Implement the libglvnd interface.

[Kyle Brenneman]

On 05/12/2016 12:58 PM, Emil Velikov wrote:
> Hi all,
>
> On 11 May 2016 at 19:53, Kyle Brenneman <kbrenneman at nvidia.com> wrote:
>> In the GLX dispatch functions, it should be safe to ignore a failed call to
>> AddDrawableMapping. If it can't update the drawable-to-vendor hashtable at
>> that point, then libGLX will just query the server when it needs to figure
>> out the vendor.
>>
> Fair enough. Any objections if we do this as a follow up change ?
No, a follow-up change seems reasonable. In practice, I doubt it will do 
any harm, since to hit that case would mean that a malloc failed for 
around 50 bytes, but everything leading up to it succeeded.
>
>> In dispatch_ChooseFBConfigSGIX, if AddFBConfigsMapping fails, should it use
>> free or XFree to free the memory?
>>
> In theory it should be XFree(). In practise that one has been a
> wrapper around free() for a long time so I've went with the latter.
>
> Kyle, Adam,
> Any suggestions about the remaining XXX hunks in
> src/glx/g_glxglvnddispatchfuncs.c ?
I'm working on some changes in libGLX which will provide dispatch 
indices for all GLX functions to all vendor libraries, including core 
functions. Once that's done, the glXCreateContextAttribsARB and 
glXCreateContextWithConfigSGIX stubs will be able to call the vendor's 
glXDestroyContext before returning.

I'm also still working on a script to generate the GLX dispatch stubs 
for a vendor, including handling things like destroying contexts. It 
should be possible to just drop that into place in Mesa and have it work.

For glXGetFBConfigFromVisualSGIX, the GLXFBConfig handle is just 
retrieved, not created, so the stub doesn't need to free anything. It 
should be safe to just return NULL.
>
> Thanks for squashing these, Adam !
>
> I've confirmed that thing haven't gone crazy through the squash, so
> barring any objections feel free to push.
>
> Note to self: Send a patch that nukes the final if
> defined(GLX_EXTENSION_FOO) hunks once these land.
>
> Thanks
> Emil
>
> P.S. I did not bother on the symbol visibility front, since GLVND's
> libGL will export every symbol imaginable.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev