On 05/12/2016 12:58 PM, Emil Velikov wrote:
Hi all,
On 11 May 2016 at 19:53, Kyle Brenneman <kbrenne...@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
