On Fri, 2016-10-28 at 17:11 +0100, Emil Velikov wrote: > > On 19 October 2016 at 18:39, Adam Jackson <a...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
