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

Adam Jackson ajax at redhat.com
Mon Oct 31 19:20:20 UTC 2016


On Fri, 2016-10-28 at 17:11 +0100, Emil Velikov wrote:
> > On 19 October 2016 at 18:39, Adam Jackson <ajax at redhat.com> wrote:
> > 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.
> > 
> 
> Personally I agree, yet the rest (past this piece) of GLVND shows that
> one is quite concerned with not making those slow.

With not making _GL_ calls slow, sure. Having already spent that effort
one might as well use the same technique for GLX though.

> Last time I've asked for some clarification [over at github] it fell
> on deaf ears.
> 
> I mean seriously we could drop a very sizeable hunk of GLVND if that's
> the case ;-)
> Of which dozen or so cases of "exit(-1)".

I have absolutely no idea what you're saying here. If _what_ is the
case? What calls to exit(-1) are there besides can't-happens in the
hash table code?

> One nitpick:
> Can we drop glXGetScreenDriver all together. Last time I've looked it
> had zero users*, it has no spec and GLVND wasn't generating an entry
> point/dispatch for it.

One user, xdriinfo(1), which is admittedly pretty useless. But the
glvnd code in mesa definitely implements dispatch for it (libglvnd
itself does not, but is not expected to).

- ajax


More information about the mesa-dev mailing list