[Mesa-dev] [PATCH 2/3] glx/glvnd: Fix dispatch function names and indices

[Adam Jackson]

On Fri, 2016-09-16 at 19:07 +0100, Emil Velikov wrote:
> On 14 September 2016 at 19:06, Adam Jackson <ajax at redhat.com> wrote:
> > As this array was not actually sorted, FindGLXFunction's binary search
> > would only sometimes work.
> > 
> 
> This commit message is a bit iffy, yet again most of this and
> g_glxglvnddispatchfuncs.c is dead code.
> 
> Afaict the sole reason behind his file is to have the vendor driver
> callback into libGLX in order to manage (add/remove) the relevant
> fbconfig/drawable/context to vendor mappings. From a quick search we
> have ~5 out of the 30+ functions that do that.
> 
> Everyone else calls back into the vendor library to a) get the correct
> vendor (dispatch) and using it dive via the vendor neutral library

Yes.

> _directly_ back into itself

No. dispatch_BindTexImageEXT (for example) is a function that the app
would be handed as the result of glXGetProcAddress. Yes it comes from
Mesa, but the drawable might belong to another vendor. So:

static void dispatch_BindTexImageEXT(Display *dpy, GLXDrawable drawable,
                                     int buffer, const int *attrib_list)
{
    PFNGLXBINDTEXIMAGEEXTPROC pBindTexImageEXT;
    __GLXvendorInfo *dd;

    /* look up which vendor is responsible for this drawable */
    dd = GetDispatchFromDrawable(dpy, drawable);
    if (dd == NULL)
        return;

    /* fetch that vendor's implementation of BindTexImageEXT */
    __FETCH_FUNCTION_PTR(BindTexImageEXT);
    if (pBindTexImageEXT == NULL)
        return;

    /* and tail call it */
    (*pBindTexImageEXT)(dpy, drawable, buffer, attrib_list);
}

The "implementation" in Mesa would be __glXBindTexImageEXT. One could
argue that dispatch_* could be smart enough to recognize their own
dispatch tables, skip the glvnd call to ->fetchDispatchEntry in
__FETCH_FUNCTION_PTR, and call the Mesa implementation directly. But
GLX function calls are not exactly hot paths, and I'm not sure the
complexity would be worth it.

> (see the generated g_libglglxwrapper.c file) to get the entry point
> via getProcAddress callback - see __glXFindVendorDispatchAddress().

Remember that getProcAddress from glvnd into the vendor library is
binary like dlsym, not unary like glXGetProcAddress. It's asking for
the implementation, not the dispatch.

- ajax