new drivers for sid!

[Luca Boccassi]

On Sat, 2016-01-23 at 20:38 +0100, Andreas Beckmann wrote:
> On 2016-01-23 19:24, Luca Boccassi wrote:
> > I have given more thought to libglvnd. Both AMD and Mesa have committed
> > to (eventually) use libglvnd as a dispatcher, and it is released under
> > an MIT-like license on Github.
> 
> Good to know.
> 
> There is this decription of what the individual libraries do:
> http://lists.freedesktop.org/archives/mesa-dev/2015-September/095856.html
> hmm, where is that libGLX?
> 
> can you draw a graph of the dependencies between the libraries? Or does
> something like this exist already?

There's a graph in the upstream README.md, you can see it on the Github
page: https://github.com/NVIDIA/libglvnd

> > A possible solution would be to package libglvnd from sources, and add a
> ACK
> 
> > new glx-alternative-glvnd that can take over libGL, libGLESv1/2 and
> NACK
> isn't the purpose to have one for all vendors?

Yes, but only Nvidia supports it for now, so only they can use the
common GL/GLES :-) But I'm fine with your plan of waiting until others
do.

> > (when it will be implemented) libEGL. We can then stop shipping those
> > libraries from the Nvidia proprietary installer, and also stop adding
> > the *nvidia slave for those .so files in glx-alternative-nvidia.
> 
> > When mesa and fglrx get around to add support, we can drop the slaves
> > from those glx-alternative-* packages too and add a dependency.
> > 
> > I've already done the packaging for libglvnd,
> Good, we cn start putting that under pkg-nvidia for now, but in the end
> this should probably live under the hands of the X/MESA maintainers.
> We should talk to them about this, you mentioned that earlier ... if you
> want, you can start that discussion (making sure that pkg-nvidia-devel
> stays Cc:ed).

Will do. When I'm done I'll push to pkg-nvidia and file an ITP and CC
the nvidia, mesa, x and fglrx lists.

> > and I've also created the
> > glx-alternative-glvnd.
> I don't want that  :-)
> 
> > Tomorrow I'll finish working on 361 and then I'll
> > test everything together and see how it works.
> Nice, but maybe wait with committing until I have 352 in sid and
> everything merged through to 358. (Only waiting for 349.16-2 to pass the
> buildds.)

Sure, no problem.

> > I'll also take out
> > libglvnd-nvidia from 355/358.
> NACK. For the beginning I want to ship nvidia's version of these
> libraries, this seems to be too much work in progress. There aren't any
> tags, yet, so do we know what commit should correspond to the shipped
> binaries ...
> And I want ship them directly in /usr/lib without any redirecting
> alternatives. :-)

I guess you mean only for the new libraries, not GL/GLES1/2. I fully
agree, I was thinking of using the alternatives just for the old 3
libraries, not the new ones :-)

> Once someone else starts to adopt them we should switch to the
> separately packaged versions.
> 
> Trying to understand the "new" libEGL works ...
> * nothing seems to use libOpenGL right now

If I understand their intentions, that's for applications to link
against, and the difference with libGL is that it's not tied to a window
system, so it's intended to be completely separate from EGL.

> * libEGL.so.1 is a stub and depends on libGLdispatch
> * libGLdispatch is used by libEGL, libOpenGL
> * the we have libEGL_nvidia.so.0 and libnvidia-eglcore.so.355.11
> * libnvidia-eglcore.so.355.11 is used by libEGL_nvidia.so.0 and
>   libGLES*.so.355.11
> * libEGL.so.1 contains the strings "__EGL_VENDOR_LIBRARY_NAME",
>   "nvidia", "libEGL_%s.so.0"
> * libEGL.so.1 uses symbol __egl_Main from libEGL_nvidia.so.0
> * there is also a string "libGLdispatch ABI version is incompatible with
> libEGL.", so libGLdispatch and the libEGL stub somehow need to be in sync
> 
> => we need a separate libegl-nvidia0 package, and that actually needs to
> use alternatives
> that package may get legacy variants, maybe called
> libegl-nvidia0-legacy-ABCxx
> 
> libegl1-nvidia will probably go away in the future (if someone else
> (MESA) provides a stub libEGL.so.1)

It appears they are still working on the EGL ABI, when that is finalised
they'll implement it and ship libEGL.so.1 from libglvnd:
https://github.com/NVIDIA/libglvnd/issues/45

Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20160124/d2c8c261/attachment-0001.sig>