355 branched and committed to SVN

[Luca Boccassi]

On Wed, 2015-10-07 at 12:00 +0100, Luca Boccassi wrote:
> Hello,
> 
> I have just created a new 355 branch to track the new upstream 355
> release. The tarball for the stable 355.11 driver has been uploaded as
> well.
> 
> What is the plan for experimental going forward?
> 
> There are quite a few changes in 2 areas: the kernel modules build
> system, and libEGL.
> 
> It is widely speculated that these changes are due to imminent support
> for Wayland (symbols in the libraries, etc).
> 
> Also the release of Vulkan should not be too far away now, and if Nvidia
> keeps the same pattern of past releases of OpenGL there will likely be a
> new driver release that implements it on the same day as Khronos
> officially releases the final version of the spec, and if so it will
> most likely happen on 355 (or higher).
> 
> Both these events are bound be of great interest to our users, so
> personally I feel we should try to move experimental to 355 as soon as
> possible to prepare and squash any bugs due to the module/EGL changes.
> 
> Andreas, Vincent, what are your opinions on this matter? Andreas, if I
> recall correctly you were planning to move 352 to unstable once the
> legacy 340xx was uploaded, is that right?
> 
> A summary of the main changes:
> 
> Regarding the kernel module, the directory structure changed and now UVM
> lives in the same top level directory as the Nvidia module, and there is
> also a new common headers directory. The Makefile and Kbuild also
> changed quite a lot. Some patches had to be simply updated to the new
> path, others are no longer relevant so I dropped them.
> 
> Main thing is that the way we override the contest.sh script no longer
> works, as it is now more ingrained in the Makefile/Kbuild system. So, I
> added 2 one-line patches (one for uvm and one for nvidia) to remove the
> dependency on that script, so that at build time it is no longer
> invoked.
> 
> Regarding libEGL, now Nvidia ships a full implementation in a
> libEGL.so.1 shared library. The old implementation no longer exposes the
> symbols but it's still there and it's still installed by the upstream
> installer, so I left it in the package (without symlinking it to libEGL
> obviously).
> 
> Also the new libEGL depends on a new library, libglvnd-nvidia, which
> implements a vendor-neutral OpenGL dispatch library, and ships
> libGLdispatch.so.0 and libOpenGL.so.0. I believe this library is open
> source and the upstream is https://github.com/NVIDIA/libglvnd but given
> there is no versioning on that repo I would think it's best not to try
> and guess what's the difference and just ship the one from the binary.
> 
> When you have time, could you please have a look and review the changes?
> 
> I ran the usual battery of tests: it builds on all architectures in
> chroots on all kernel versions, and on Jessie amd64 Gnome loads fine on
> kernel 4.2, 4.1 and 3.16, and it runs also fine in 2d, 3d, OpenCL and
> Cuda, on both a desktop system with a 780 and an Optimus laptop with a
> 720m (through Bumblebee).

A new beta release, 358.09, is out. It adds a new kernel module,
nvidia-modeset, as another step toward Wayland support.

I've branched 358 from 355, eventually if we decide to never ship either
of those we can delete one of them. I'll upload the tarball tomorrow.

I ran the usual battery of tests, and all looks fine besides the problem
spotted with libEGL.so.1 on 355.11, that still persists.

Kind regards,
Luca Boccassi