[Mesa-dev] [Bug 98428] Undefined non-weak-symbol in dri-drivers

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98428

--- Comment #11 from Kyle Brenneman <kyle.brenneman at gmail.com> ---
(In reply to Emil Velikov from comment #10)
> (In reply to Kyle Brenneman from comment #9)
> > > > >  - And last but not least - reuse GLVND dispatch. For this we would need to
> > > > > convince Kyle that GLdisplatch.so can be accessible by vendors and it gets
> > > > > some ABI stability (note the GLVND libraries in general seem ABI unstable).
> > > > 
> > > > We're likely to want libGLdispatch to be stable API anyway, yes. Consider
> > > > this bit of discussion:
> > > > 
> > > > https://github.com/NVIDIA/libglvnd/pull/100#issuecomment-254588402
> > > 
> > > I've mentioned a similar thing [1] [2] and it seems that one "has to" go
> > > through the winsys library/ies [2].
> > > 
> > > Even convincing to version GLdispatch.so ended up quite a process [3].
> > > 
> > > My personal favourite: "To clarify: libGLdispatch.so does not have an ABI." 
> > > Sure it doesn't ... ;-)
> > > 
> > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=92877#c2
> > > [2] https://github.com/NVIDIA/libglvnd/pull/85
> > > [3] https://github.com/NVIDIA/libglvnd/issues/59.
> > 
> > libGLdispatch.so doesn't have an ABI because it has no direct interface *at
> > all* to applications or drivers. The entire interface is defined in
> > libGLX.so and libEGL.so, including anything that passes through to
> > libGLdispatch.so.
> > 
> libGLdispatch.so _has_ ABI - that's how libGLX.so and others use it. Sure
> it's private, unstable, etc. and that's fine. It is an ABI regardless and
> ignoring that won't make it disappear ;-)
> 
> > Now, providing more direct control over the dispatch tables is something
> > that's come up before. This is the current version of that:
> > https://github.com/NVIDIA/libglvnd/pull/89
> > 
> > I don't have a good enough understanding of what Mesa needs out of it to be
> > sure if that's sufficient, but if that overall design looks like it would
> > work, then I'd be happy to dust it off and get it updated for the current
> > EGL and GLX interfaces.
> As said a couple of times before (iirc Adam also said it as well) - exposing
> it via the winsys is not going to work.
> 
> The DRI modules also use the dispatch (due to $reasons) and they are winsys
> agnostic. If you're interested in specifics check the following:
> 
> $ git grep "\<\(CALL\|SET\)_[A-Z][a-z][a-zA-Z0-9]*"
> 
> To iterate - we _want_ to make the GLdispatch API/ABI accessible for
> vendors, since everyone will benefit from it. This is something that was
> implicitly mentioned on the initial design stages/proposal.

I'll read through and look for the CALL/SET_ calls. The critical question for
libGLdispatch, though: Does Mesa rely on changing the entries in dispatch
tables on the fly, or does it just need to construct a few in advance and
switch between them?

As for the details of what libGLdispatch would need to do, we should probably
move the discussion over to the libglvnd thread instead of cluttering up this
one.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161101/d3a89dec/attachment.html>