I’ve just pushed a big update to the Nvidia repository. The list of changes is quite big, so if you are a user of the repository please take your time to read through it.
Table of Contents
CUDA
CUDA has been replaced with version 7 for all supported RHEL/CentOS/Fedora releases, with the main difference being no more support for 32 bit systems. From now on, there will be no compatibility packages for the i686 architecture. So, after upgrading, make sure to remove all the i686 pacakges (that is, yum/dnf remove cuda\*.i686).
Apart from this, CUDA 7 packages introduce new stuff, improves on the packaging and can now run correctly on all Fedora systems, including Fedora 22, which was not supported by CUDA 6.5. As announced previously, the only “regression” is when enabling C+11 on GCC 5.1 (i.e. Fedora 22).
The new packages take into consideration the Nvidia provided ones, and replace them accordingly; so if you have their packages installed it should upgrade them where appropriate leaving no traces of the former. Local changes include the pkg-config files for development packages (not included in their self installer and in my 6.5 packages) and the segregation of static libraries in their own subpackage, thus reducing installed size greatly. The next step is to proceed like for the open components of the Nvidia driver: replacing all the pre-built binaries with source compiled stuff. At the moment, this includes cuda-gdb, for which sources do exist.
NVIDIA driver
The Nvidia driver has seen a repackaging of the main components, where the biggest change is the library layout.
All the unique libraries are now in standard locations, leaving only the duplicate ones under /usr/lib{,64}/nvidia. Also, X configuration files that the user should avoid touching, have been moved under /usr/share/X11/xorg.conf.d. Library dependencies have been reduced, so you can now compile a program against the NVML library (libnvidia-ml.so.1) or CUDA without needing to install the full driver or using the Nvidia provided stubs.
This makes for a simpler package with a simpler filter for conflicting libraries and is also propedeutic work to enable hardware accelerated encoding with Steam In-Home streaming and Nvidia drivers. Hardware decoding in Steam has been put in place, so now it’s time for the (only) supported hardware encoding.
NVIDIA beta driver (355.xx)
The biggest change comes with the 355.06 driver in Fedora 23, which introduces partial support for the GL Vendor-Neutral Dispatch library (libglvnd), a new kernel module building system (in preparation for their modeset driver after the 355.x series) and dropped support for Nvidia instanciated modules.
The new beta driver requires the GL Vendor Neutral Dispatch library in place for proper operation, and being this a separate open source project (only a prototype in Mesa, at the moment) it has been built from source. So there is now a required libglvnd package that only contains the libraries required by the driver for running. The more they are integrated with the driver, the more I will enable in the package. This is a transitional package only, as sooner or later Mesa and the X server will introduce the same mechanism, making the transitional package obsolete and just using distribution provided packages.
This with could eventually lead to system running different OpenGL implementations at the same time, solving the Optimus and multiple cards from multiple vendors combination issues.
The Nvidia control panel can be optionally linked to NVML, so I’ve tried to enable it in the beta drivers. I don’t see any changes so far, but probably this is due to the fact that I don’t have new enough cards to be compatible with NVML.
The beta driver has been pushed to the Fedora 23 branch only, as explained in the Nvidia repository page.
As always, feedback is welcome.
CUDA 7.5 is out, any plan to add it to repo?
Pretty soon, actually. I’ve some other Fedora related things to check and then will do it.
Still not working on current F23 pos alpha Kernel.
Latest 355 has the tainted GPL violation symbols, so dkms is not compiling.
Based on nvidia forums, there’s no fix unless you recompile kernel with symbol not marked.
That’s a policy for every pre-release kernel (not Fedora specific), you can not load any external module unless it’s GPL. This is changed before the final kernel release. The only way to make it work is to fake the license in the Nvidia module. If you want to test on your system just apply this small change on your local sources installed by
dkms-nvidia:http://negativo17.org/repos/nvidia/nvidia-gpl-hack.patch
Looks nice, may end up using your site for my new computer over rpmfusion as I want CUDA working.
What about support for Bumblebee on laptops with your repository? This is a headache on new Nvidia based laptops and optimus. I know as I have two of them.
Bumblebee is totally unrelated to CUDA, and personally I think is a hack. Unfortunately at the moment there’s no direct replacement, so I run the GPU offloading configuration as described in Nvidia’s docs. Please see the following:
http://negativo17.org/complex-setup-with-nvidia-optimus-nouveau-prime-on-fedora-20/
ftp://download.nvidia.com/XFree86/Linux-x86_64/355.06/README/randr14.html
So you are saying that you can use CUDA without the NVIDIA video drivers? I thought they where both needed.
Thanks for the link, I will look at trying to get NVIDIA working on both laptops this way.
CUDA packages are required to build binaries for GPU consumption, and you might need them also if you link shared objects in them. If you link them statically, the only thing you need to run a CUDA enabled application is the Nvidia proprietary driver.
In fact I’m building all CUDA packages on a non-Nvidia powered system.
Does this small utility run correctly?
http://sourceforge.net/projects/cuda-z/
Rgds
AW
Don’t know, you should try.
Any idea how to test wayland with nVidia driver at that point?
There are references to libnvidia-wayland & co, so I guess they are already experimenting with it.
The
libnvidia-wayland.soobject and thenvidia-modeset.komodule are not yet available. I guess they will enable them at the same time. In the 355.xx announcement they wrote that there will be no new kernel modules in the 355.xx timeframe, so at a minimum the new kernel module is a few months away.Instead of providing your own dkms.conf file why not just modify the nvidia provided template file? After looking at the source for the nvidia-installer, it’s actually rather basic.
You would start by copying and including the .manifest file into your tar’d dkms sources. And then you can do:
jobs=%{_smp_mflags:1}
sed -i -e "s/__VERSION_STRING/%{version}/" \
-e "s/__JOBS/${jobs#-j}/" \
-e "s/__EXCLUDE_MODULES//" \
-e "s/__DKMS_MODULES//" \
/path/to/dkms.conf
index=0
for mod in $(gawk 'NR==4' ../.manifest) ; do
echo "BUILT_MODULE_NAME[$index]=$mod" >> /path/to/dkms.conf
echo "DEST_MODULE_LOCATION[$index]=\"/kernel/drivers/video\"" >> /path/to/dkms.conf
index=$((index+1))
done
Are you referring to the 355.xx drivers, right? I’m not sure this is really better, the nvidia provided one does not have
IGNORE_XEN_PRESENCE=1 IGNORE_PREEMPT_RT_PRESENCE=1and simply adding a new file is easier than adding the file and clutter the spec file with all these adjustments.Will look at it anyway, thanks.