[Mesa-dev] [PATCH 1/3] glx: Implement the libglvnd interface.
Adam Jackson
ajax at redhat.com
Thu May 12 21:10:15 UTC 2016
On Thu, 2016-05-12 at 19:58 +0100, Emil Velikov wrote:
> > 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.
It's sort of a weird question. If we care about working on Windows, or
other (fairly idiotic) platforms where you have to malloc and free from
the same object, then it should be XFree _and_ it should have been
allocated with Xalloc by the vendor library.
I don't know if that's a problem we care to solve.
> Kyle, Adam,
> Any suggestions about the remaining XXX hunks in
> src/glx/g_glxglvnddispatchfuncs.c ?
I'd opened a glvnd ticket about it:
https://github.com/NVIDIA/libglvnd/issues/88
Personally I think the sanest thing is to make staticDispatch not
opaque to the vendor library. It's not like GLX (or EGL) are radically
evolving APIs. But let's have that discussion on the ticket.
> P.S. I did not bother on the symbol visibility front, since GLVND's
> libGL will export every symbol imaginable.
Indeed, I'm just wanting to be cautious. Even ignoring efficiency
concerns, the fewer places we can give symbol resolution a place to go
wrong, the better. Unfortunately we still end up exporting all the GL
entrypoints, but it's difficult to fix that while still building in one
pass without glvnd getting full EGL support first (since the glapi bits
end up linked into our libGLES* as well).
- ajax
More information about the mesa-dev
mailing list