Nvidia proprietary and open source kernel modules

With the latest bunch of updates to the Nvidia and Multimedia repositories, I’ve added the ability to switch to the two implementations of the kernel modules currently available in the Nvidia driver for Linux.

Since almost a year, the Nvidia driver ships with two different implementations of the kernel modules, one proprietary and one open source. The open source one as of drivers 545.x is now considered beta quality also for the workstations, so it seems a good moment to start shipping it.

The open source one is supposed to be the only one that will be kept in the future, but at the moment both are available and both differ in terms of functionality. You can read about the main differences in terms of functionality and what chips they support in the official documentation.

I did not want to introduce another variation of the kernel modules beside akmods, kABI and DKMS, this would have created even more confusion and lots of dependencies in the SPEC files for the variations. The new akmod and DKMS packages ship both sources (MIT/GPL and proprietary kernel modules) and allow you to switch between one or the other through a configuration file.

Considering that in the long run only the open source variant will remain, I wanted to make this as transparent as possible for the users. Basically, if you don’t care and just want something that works, nothing has changed for you.

The two sources get referenced as they are referenced inside the Nvidia run file, namely “kernel” for the original proprietary kernel modules and “kernel-open” for the new open source variation.

The following instructions show you how to switch between one implementation or the other.

DKMS

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

Change the type of modules you want to use and trigger a rebuild and a reinstall:

# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# dkms build -m nvidia/545.29.02 --force
# dkms install -m nvidia/545.29.02 --force

Now check again the license and you should see that it has changed to MIT/GPL:

# modinfo -l nvidia
Dual MIT/GPL
# reboot

To switch back, change the configuration again and then trigger the same process for rebuilding installing:

# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# dkms build -m nvidia/545.29.02 --force
# dkms install -m nvidia/545.29.02 --force
# reboot

akmods

Check which version you have installed:

# modinfo -l nvidia
NVIDIA

Change the type of modules you want to use and trigger a rebuild and a reinstall:

# sed -i -e 's/kernel$/kernel-open/g' /etc/nvidia/kernel.conf
# akmods --rebuild

Now check again the license and you should see that it has changed to MIT/GPL:

# modinfo -l nvidia
Dual MIT/GPL
# reboot

To switch back, change the configuration again and then trigger the same process for rebuilding installing:

# sed -i -e 's/kernel-open$/kernel/g' /etc/nvidia/kernel.conf
# akmods --rebuild
# reboot

Wayland/modesetting on Nvidia

With the latest Nvidia drivers it seems that modesetting and Wayland work fine for Gnome and GDM.

Console text is still a normal console, but upon boot you get the native screen resolution in Plymouth and then you can login under both X.org and Wayland sessions.

Screenshot-from-2020-07-11-08-06-56

How to test? Make sure that you have the following line enabled for the nvidia-drm module:

# cat /usr/lib/modprobe.d/nvidia.conf | grep drm
options nvidia-drm modeset=1

And then make sure to comment out the following line in the udev rules supplied by GDM:

# cat /usr/lib/udev/rules.d/61-gdm.rules | grep -i nvidia
# disable Wayland when using the proprietary nvidia driver
#DRIVER=="nvidia", RUN+="/usr/libexec/gdm-disable-wayland"

Then reboot, and you will login with a Wayland session by default:

# cat /sys/module/nvidia_drm/parameters/modeset 
Y
# cat /sys/module/nvidia_drm/version 
450.57
$ lsmod | grep nvidia
nvidia_drm             57344  4
nvidia_modeset       1187840  3 nvidia_drm
nvidia_uvm           1130496  0
nvidia              19726336  208 nvidia_uvm,nvidia_modeset
drm_kms_helper        249856  1 nvidia_drm
drm                   618496  7 drm_kms_helper,nvidia_drm
$ env | grep XDG_SESSION_TYPE
XDG_SESSION_TYPE=wayland
$ lspci | grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1)

HandBrake with NVENC support

After switching from libav to FFmpeg, the HandBrake developers quickly added NVENC encoder support to HandBrake. You can now select both NVENC for H.264/H.265 encoders in the drop down menu or with the command line interface:

$ HandBrakeCLI --help | grep -A12 "Select video encoder"
   -e, --encoder   Select video encoder:
                               x264
                               x264_10bit
                               nvenc_h264
                               x265
                               x265_10bit
                               x265_12bit
                               nvenc_h265
                               mpeg4
                               mpeg2
                               VP8
                               VP9
                               theora

With most GPUs I tried, even setting the slowest and costly preset results in the video engine not being fully utilized. Encoding times are cut to ~25%.

Awesome! No more ffmpeg command line black magic. You can now comfortably create your preset in the HandBrake gui and then use HandBrakeCLI through SSH on your awesome Plex Media Server. The build is available for both CentOS/RHEL 7 and Fedora.

HandBrake FFmpeg, no more Nvidia 32 bit drivers

HandBrake has been updated again to track the master branch, as it now uses FFMpeg 4 and no longer libAV 12. This could probably lead to other improvements, like NVENC/CUDA support, more formats, etc.

Starting with the Nvidia drivers version 396.24 there will be no more 32 bit support, the driver will be 64 bit only. The 32 bit libraries are still included, so Steam and other applications will keep on being supported.

In a few days, the updated drivers will be pushed in the Fedora repositories, and at the same time I will also remove the i386 folder from the repositories. Some i386 packages will still be provided in the x86_64 folder, as it is now for Fedora 28 and CentOS/RHEL 7. The packages that will be kept, are mostly multilib library packages.

The same will happen to CentOS/EPEL 6 at the moment a new 64 bit only driver series will be nominated as “Long Lived”.

Also the Spotify repository has already no more i386 support, upstream stopped providing updated clients. Judging from the web server logs, there seems to be almost no one using an i686 Fedora in conjunction with the repositories hosted here.

CUDA 9.0, cuDNN 7.0 and Wayland support in Fedora 27

The Nvidia repository now contains packages for Fedora 27. This is with the release candidate of CUDA 9, and it contains also cuDNN at version 7.0, which is the only version supported with CUDA 9 at the moment of writing.

The updated cuDNN 7.0 library has been added also to the other branches, this means it will be automatically upgraded from version 6.0 to 7.0. If you still need one of the previous versions, just remove it and install one of the compatibility packages:

# dnf list cuda-cudnn*
Installed Packages
cuda-cudnn.x86_64                   1:7-1.fc26         @fedora-nvidia
Available Packages
cuda-cudnn-devel.x86_64             1:7-1.fc26         fedora-nvidia 
cuda-cudnn5.1.x86_64                1:5.1-2.fc26       fedora-nvidia 
cuda-cudnn5.1-devel.x86_64          1:5.1-2.fc26       fedora-nvidia 
cuda-cudnn6.0.x86_64                1:6.0-1.fc26       fedora-nvidia 
cuda-cudnn6.0-devel.x86_64          1:6.0-1.fc26       fedora-nvidia 

CUDA 9 supports GCC 6.x and CLANG 3.9, so when it will be officially released, it will cover Fedora 25 and RHEL/CentOS compilers. With Fedora 27, there will be the usual need for a GCC compatibility package (like the compat-gcc53 package currently in the repository) as GCC is at version 7 and CLANG is at version 4.0.

I will try to provide a compat-gcc64 for Fedora 27+ at the time of the official CUDA 9 release.

Regarding the drivers, on Fedora 27 where Mutter 3.25+ is available, the modesetting part of the Nvidia drivers has been enabled by default, this means that at the login you can just select “GNOME” to run Gnome on Wayland. Please note that X 3D programs running on XWayland might not work properly.

Plex Media Player and MPV with CUDA

The Plex Media Player is now part of the multimedia repository for Fedora 25+. I works as a standalone player and also as the main interface for an HTPC setup, where the “TV interface” starts as the main thing when you power up your system.

Plex Media Player uses MPV in the background, so any compilation option that was added to MPV, is now also part of Plex Media Player by using the same libraries that were already available in the multimedia repository.

If you are using Gnome Software, you will also find it in the software selection screens.

To install it on Fedora, just perform the following commands:

dnf -y install plex-media-player

You will then find it along with the other applications in your menu.

Normal desktop interface

To get to the normal desktop interface just look for the Plex Media Player icon in your menu. You will be greeted with the familiar Plex web interface, with the main difference being that the player is local through the MPV library.

Enabling Plex Media Player startup at boot

If you are planning to do an HTPC installation, and would like to have Plex Media Player starting instead of the login screen the moment you boot the device, execute the following commands as root:

dnf install plex-media-player-session
systemctl set-default plex-media-player
echo "allowed_users = anybody" >> /etc/X11/Xwrapper.config

The first command installs the required files (services, targets and PolicyKit overrides). The second command instructs the system to load by default the Plex Media Player target; that is X immediately followed by the player itself. The third command allows the system to start the X server as the Plex Media Player user, otherwise only users logged in through a console or root can start it.

You will be greeted with the TV interface just after boot:

If you want to go back to your normal installation (let’s say Gnome), then revert back the changes (again type the following commands as root):

systemctl set-default graphical
sed -i -e '/allowed_users = anybody/d' /etc/X11/Xwrapper.config
rpm -e plex-media-player-session

MPV with CUDA

This has been already available for a long time, but with FFmpeg 3.3, CUDA dynamic support loading is enabled also in MPV, so the hard dependency on the CUDA library is gone, and the binaries load the library dynamically:

$ strings /usr/bin/mpv | grep libcuda
libcuda.so.1
$ strings /usr/lib64/libmpv.so.1.25.0 | grep libcuda
libcuda.so.1

So assuming you have the Nvidia driver already installed with the appropriate CUDA part, you can then play a video with the following command line:

mpv --hwdec=cuda /path/to/video.file

And then check with nvidia-smi or with the Nvidia control panel if the video engine is being utilized:

If you want to enable that by default, just make sure your configuration file has something like this inside:

$ cat ~/.config/mpv/mpv.conf 
#hwdec=vdpau
#vo=vdpau
hwdec=cuda

Nvidia driver improvements for Fedora 25+

The Nvidia repository now contains all the remaining bits for the work done by Hans De Goede.

Making an Optimus laptop work as expected with the Nvidia drivers should be much less painful than it was a few years ago and most of the things should work out of the box on Fedora 25+.

Just enable the repository on a pristine Fedora installation, and after a while you should be able to search for Nvidia, CUDA, GeForce to Quadro to make the driver, control panel and other programs appear in your Gnome Software search:

Optimus laptops

The driver should install and operate cleanly whether you are installing it on a system which has one or more discrete Nvidia cards or an Optimus laptop with an Intel and a Nvidia card. Nothing to do to enable or configure Optimus.

This is up to the point that when the drivers are installed, you can even turn off Optimus on or off in your system Bios (if your laptop allows that) and the only difference you should see is that there’s an additional VGA card enabled in your system (check with lspci) and that the Nvidia control panel switches between a PRIME Display, like in this picture:

And a normal RandR managed one, like in this one:

Everything else should not be different from your normal experience.

Limitations

Nvidia driver

The limitations are the same as provided by the Nvidia driver, this means that if you are running it on an Optimus laptop, the Intel card can never power off. Which means higher power consumption, unfortunately. If you have an Optimus laptop and absolutely need the proprietary drivers, my suggestion is still to disable Optimus in the Bios.

OSS stack

On the contrary, if you use the OSS stack (nouveau/intel) the second card can be powered off if there’s no application running on it or display directly connected to one of the card’s outputs. That’s the best reason to use the OSS drivers at all if you you’re not doing serious gaming or 3D work:

$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0

You also got the nifty selection menu about running your game on the discrete card on Gnome, which is really cool:

It will power up the video card just before launching the process. Launching a program through that menu entry is like starting it from the command line with the DRI_PRIME variable declared. For example, the same as above would be:

$ DRI_PRIME=1 quake3 &
$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynPwr:0000:01:00.0

As you can see, the discrete video card is turned on. For Steam, you still need to edit each of your game to run on the Nvidia card:

SLI systems

SLI is now enabled by default with the Auto profile, there’s nothing to do if you have a SLI system. If you need any different SLI option (AA, SFR, etc.), just override it in X.org configuration files.

Nouveau fallback

With the new expanded OutputClass support for X, as carried out by Hans, it’s now super easy to switch to the OSS stack if the proprietary Nvidia driver somehow does not work. No user space component is touched, as soon as the Nvidia kernel module is not loaded (check on /sys/module/nvidia), the desktop starts with the normal OSS components you get with a normal installation. Thanks to all the work done on libglvnd, the libraries loaded are the correct one for the driver you are running.

This means that the performance of the Nvidia card would be abysmal, but still you would get a nice desktop and browser to Google around for answers on how to fix it :).

Upgrade path from Nvidia CUDA, ELRepo and RPMFusion repositories

The current packages should allow you to upgrade if you have any Nvidia component installed on your system from one of the mentioned repositories. All upgrade paths, obsolency and packaging rename should be taken into account.

This has been cool for a few years, and actually helped me a lot in migrating some installed CUDA clusters to the packages hosted here. As part of ongoing discussions with a few parties (mostly Red Hat), this is going to disappear to allow later an opposite upgrade path to one of the other repositories (RPMFusion/Nvidia).

As of the 15th of May, all Nvidia packages will be marked with Conflicts instead of Obsoletes/Provides for all the other repositories out there. I will update the installation and repository page accordingly. If you have anything installed from the RPMFusion, ELRepo or CUDA repository from Nvidia and want to switch to the packages here after the 15th of May, you must “wildcard remove” all Nvidia and CUDA packages on your system prior to proceeding with the installation.

I’m not planning to remove any other feature in terms of capability or packaging option.

Compatibility GCC 5.3.1 package for Fedora

As some might have noticed, since a few days there’s a new compat-gcc-53 package in the Fedora repositories. This is only intended for compiling CUDA programs on Fedora where the latest update to Clang 3.9 actually broke the last compiler compatible with CUDA 8.

$ rpm -ql compat-gcc-53 compat-gcc-53-c++ | grep /bin/
/usr/bin/gcc53
/usr/bin/gcov53
/usr/bin/g++53

If you need to build a package using it, you can check for examples in the Blender and CCMiner packages as in the multimedia repository:

https://github.com/negativo17/blender/blob/master/blender.spec#L57-L61
https://github.com/negativo17/blender/blob/master/blender-2.78a-cuda.patch#L19-L23
https://github.com/negativo17/ccminer/blob/master/ccminer.spec#L75-L82

This way, I was able to provide the Blender package with CUDA support also on Fedora 26 even after the Clang update from 3.8 to 3.9.

The package is also available as a COPR repository if you prefer to use official Nvidia CUDA packages instead of the ones provided here.

To do list

Figure out what to do with the PRIME Synchronization configuration:

https://github.com/negativo17/nvidia-driver/issues/13
https://github.com/negativo17/nvidia-driver/blob/master/nvidia.conf#L2-L5

All reports have been mixed so far. On my systems (including a SLI one) works fine.

Big multimedia repository update (CUDA enablements, rebases, new software)

Merging of the Nvidia repository into Multimedia

The whole multimedia repository has been rebased with recent releases, and it now features FFmpeg 3.2 as the foundation. Most of the programs that suppport some Nvidia integration are now enabled and compiled with support for CUDA/NVENC/CUVID; leveraging the previous reorganization of CUDA 8 in the various subpackages.

This means that all the Nvidia packages are now included in the repository as well, so if you have an Nvidia card and you are interested in both repositories, you can just have the multimedia repository enabled. If you still just want the Nvidia stuff (as enabled in Fedora 25) then it’s still available as a separate repository; and that will not change.

Why all of this? Because I can’t keep them separated anymore. The Nvidia repository can exist on its own, but the multimedia one can’t, due to the dependencies and the constant rebases (also of main Fedora and CentOS/RHEL packages). You can use the Nvidia repository alone, if you just need that, or use the multimedia one if you need everything else.

The repository is now exposed also at this URL, and contains Delta RPM support:

https://negativo17.org/repos/multimedia

All repository files and configurations have been updated, so this means that in the future this would be the place where the metadata and repository information will be placed and any new installation will get the repository from there. If you are reading this blog post, you can switch now. I will add a negativo17-release package soon, along with a few mirrors; I’m sorting out the details now with the mirror owners.

FFmpeg and other CUDA enablements

To make proper use of the Nvidia hardware encode features (NVENC/CUVID) and CUDA kernel support (i.e. Blender GPU rendering) in the various programs you need the Nvidia driver installed (nvidia-driver-cuda), and for Nvidia Performance Primitives you require the CUDA driver and the NPP library package (cuda-npp).

This means that for most people NOT requiring CUDA support or not using an Nvidia video card, the following 2 packages will be installed anyway:

$ ls -alghs nvidia-driver-cuda-libs*.rpm cuda-npp*.rpm 
92M -rw-r--r-T. 1 mock 92M Nov 16 12:35 cuda-npp-8.0.44-6.fc25.x86_64.rpm
22M -rw-r--r-T. 1 mock 22M Nov 19 15:00 nvidia-driver-cuda-libs-375.20-1.fc25.x86_64.rpm

Both packages contain just libraries, and they will be on your system as much as other libraries for multimedia codecs you don’t actually need. Example, with most multimedia programs you will get Xvid libraries for opening Xvid files, even though the format is pretty much abandoned. Having them installed does not enable any unwanted feature in your system. Also, NPP libraries should decrease 50% in size in one of the next CUDA updates, being the monolithic version of the library being deprecated in favor of split functionality.

There are some patches being evaluated to make those libraries loadable at runtime, but they have not been merged yet and there’s no guarantee that they ever will. Also, they are available for FFmpeg but not for all the other programs where support has been enabled for; so depending on your installation, you might get them anyway.

As of today, from the Multimedia repository the following programs have been enabled with some Nvidia hardware enablement:

  • MPV (video decoding through CUVID)
  • FFmpeg (encoding through NVENC, decoding through CUVID and filtering through CUDA NPP)
  • Avidemux (encoding, through NVENC)
  • GStreamer (NVENC plugin)
  • Blender (GPU rendering)

VDPAU for decoding was already enabled where possible.
Of course anything that is using FFmpeg (like the GStreamer plugins) could theoretically benefit from the same enablements as in FFMpeg:

$ for i in encoders decoders filters; do
    echo $i:; ffmpeg -hide_banner -${i} | egrep -i "npp|cuvid|nvenc|cuda"
done
encoders:
 V..... h264_nvenc           NVIDIA NVENC H.264 encoder (codec h264)
 V..... nvenc                NVIDIA NVENC H.264 encoder (codec h264)
 V..... nvenc_h264           NVIDIA NVENC H.264 encoder (codec h264)
 V..... nvenc_hevc           NVIDIA NVENC hevc encoder (codec hevc)
 V..... hevc_nvenc           NVIDIA NVENC hevc encoder (codec hevc)
decoders:
 V..... h263_cuvid           Nvidia CUVID H263 decoder (codec h263)
 V..... h264_cuvid           Nvidia CUVID H264 decoder (codec h264)
 V..... hevc_cuvid           Nvidia CUVID HEVC decoder (codec hevc)
 V..... mjpeg_cuvid          Nvidia CUVID MJPEG decoder (codec mjpeg)
 V..... mpeg1_cuvid          Nvidia CUVID MPEG1VIDEO decoder (codec mpeg1video)
 V..... mpeg2_cuvid          Nvidia CUVID MPEG2VIDEO decoder (codec mpeg2video)
 V..... mpeg4_cuvid          Nvidia CUVID MPEG4 decoder (codec mpeg4)
 V..... vc1_cuvid            Nvidia CUVID VC1 decoder (codec vc1)
 V..... vp8_cuvid            Nvidia CUVID VP8 decoder (codec vp8)
 V..... vp9_cuvid            Nvidia CUVID VP9 decoder (codec vp9)
filters:
 ... hwupload_cuda     V->V       Upload a system memory frame to a CUDA device.
 ... scale_npp         V->V       NVIDIA Performance Primitives video scaling and format conversion

I think this will be much appreciated for you users out there that are already using CUDA for deep learning and FFMpeg to process data 🙂

Rebases: FFmpeg, HandBrake, VLC, OpenH264, WebP (CentOS/RHEL), MPV.

A note on Blender: Blender with CUDA support is still at 2.78 built with CUDA 7.5, and not 2.78a built with CUDA 8; so no Nvidia Pascal GPU support. I’m working on it.

GNOME Software integration

Most of the graphical software is now enabled in GNOME software for Fedora 25, meaning that you can search stuff with a keyword and that if you have the repository enabled it will just pop-up:

gnome-software-handbrake

gnome-software-makemkv

gnome-software-vlc

There is still some packages that need AppStream metadata, but that will come.

As usual, feedback, bugs and comments are welcome.

CUDA 8, cuDNN, Nvidia drivers and GNOME Software metadata

GNOME software integration

The Nvidia driver repository has been updated with AppStream metadata. From Fedora 25 onward, you will be able to search for Nvidia, CUDA, GeForce or Quadro to make the driver, control panel and other programs appear in the Gnome Software window.

As far as I know, this should be enabled by default on Fedora 25.

gnome-software-nvidia

Thanks to Richard Hughes for helping out with the metadata.

I require proper 16:10 aspect ratio pictures for both NSight and the Visual Profiler running on Fedora, so if you want to contribute just drop me an email or open an issue on the CUDA package on GitHub.

Changes to the Nvidia driver packaging

The Nvidia driver can now be installed without nvidia-settings (the control panel utility) as requested by Red Hat, in preparation for the Gnome software integration. This means the dependencies have been reversed, and that to install the driver and the control panel you need to install nvidia-settings or the driver and nvidia-settings:

dnf/yum -y install nvidia-settings kernel-devel

The libglvnd package has been updated to the latest snapshot and now features all the changes that have been introduced by Adam Jackson for the Mesa GLVND integration in Fedora 25. This means that while installing you will be prompted to install/upgrade smaller packages that contain a subset of the libglvnd libraries, this includes EGL support for the recently released beta drivers version 375.10. For anything lower than 375.10 (so Fedora 23-24 and CentOS/RHEL 6/7 at the moment of writing this) Nvidia’s last official note on EGL is:

“libEGL.so.1, while not a proper GLVND library, depends upon the GLVND infrastructure for proper functionality. Therefore, any driver package which aims to support NVIDIA EGL must provide the GLVND libraries […]”

So for now, in Fedora 23, 24 and CentOS/RHEL 6/7:

$ rpm -q --requires nvidia-driver-libs.x86_64 | grep libglvnd
libglvnd-gles(x86-64) >= 0.1.1
libglvnd-glx(x86-64) >= 0.1.1
libglvnd-opengl(x86-64) >= 0.1.1
$ rpm -q --conflicts nvidia-driver-libs.x86_64 | grep libglvnd
libglvnd-egl(x86-64) >= 0.1.1

And for Fedora 25:

$ rpm -q --requires nvidia-driver-libs.x86_64 | grep libglvnd
libglvnd-egl(x86-64) >= 0.2
libglvnd-gles(x86-64) >= 0.2
libglvnd-glx(x86-64) >= 0.2
libglvnd-opengl(x86-64) >= 0.2

Not a big deal. This accommodates the ongoing modularization in Mesa but still preserves the original EGL libraries from Nvidia. The upgrade should be transparent and you should not notice any difference except some smaller packages being installed.

vulkan_500px_june16Vulkan is now part of Fedora, so on supported Fedora releases, the Vulkan loader and libraries can be installed and you do not need to do anything to enable support in the drivers. CentOS and Red Hat Enterprise Linux do not have Vulkan yet. I’m not sure if it’s worth installing it by default along with the drivers, though.

Let’s assume you have a freshly installed Fedora 25 system with a recent Nvidia GPU and you want to:

  • Install the driver for gaming
  • Play Vulkan enabled games
  • Want to be comfortable with the control panel
  • Play 32 bit games on a 64 bit system
  • Play 32 bit Vulkan games on a 64 bit system
$ sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686
Last metadata expiration check: 0:33:49 ago on Mon Oct 24 14:14:30 2016.
Dependencies resolved.
=====================================================================================
 Package            Arch   Version                             Repository       Size
=====================================================================================
Installing:
 dkms-nvidia        x86_64 2:375.10-1.fc25                     fedora-nvidia   6.4 M
 libglvnd           i686   1:0.2.999-4.20161025git28867bb.fc25 fedora-nvidia   103 k
 libglvnd           x86_64 1:0.2.999-4.20161025git28867bb.fc25 fedora-nvidia   105 k
 libglvnd-egl       i686   1:0.2.999-4.20161025git28867bb.fc25 fedora-nvidia    44 k
 libglvnd-egl       x86_64 1:0.2.999-4.20161025git28867bb.fc25 fedora-nvidia    42 k
 libglvnd-gles      i686   1:0.2.999-4.20161025git28867bb.fc25 fedora-nvidia    29 k
 libglvnd-gles      x86_64 1:0.2.999-4.20161025git28867bb.fc25 fedora-nvidia    28 k
 libglvnd-glx       i686   1:0.2.999-4.20161025git28867bb.fc25 fedora-nvidia   114 k
 libglvnd-glx       x86_64 1:0.2.999-4.20161025git28867bb.fc25 fedora-nvidia   110 k
 libglvnd-opengl    i686   1:0.2.999-4.20161025git28867bb.fc25 fedora-nvidia    39 k
 libglvnd-opengl    x86_64 1:0.2.999-4.20161025git28867bb.fc25 fedora-nvidia    38 k
 libva-vdpau-driver x86_64 0.7.4-14.fc24                       fedora           61 k
 libvdpau           i686   1.1.1-3.fc24                        fedora           35 k
 nvidia-driver      x86_64 2:375.10-3.fc25                     fedora-nvidia   3.1 M
 nvidia-driver-NVML x86_64 2:375.10-3.fc25                     fedora-nvidia   397 k
 nvidia-driver-libs i686   2:375.10-3.fc25                     fedora-nvidia    15 M
 nvidia-driver-libs x86_64 2:375.10-3.fc25                     fedora-nvidia    14 M
 nvidia-libXNVCtrl  x86_64 2:375.10-1.fc25                     fedora-nvidia    26 k
 nvidia-settings    x86_64 2:375.10-1.fc25                     fedora-nvidia   935 k
 vulkan             i686   1.0.30.0-1.fc25                     updates-testing 1.5 M
 vulkan-filesystem  noarch 1.0.30.0-1.fc25                     updates-testing 8.0 k

Transaction Summary
=====================================================================================
Install  21 Packages

Total download size: 42 M
Installed size: 178 M
Is this ok [y/N]:

Note that the requirement on kernel-devel is still required as otherwise the package kernel-debug-devel is pulled in automatically in place of the normal non-debug package. There is bug opened on dnf/libsolv for this.

Changes to CUDA packaging

The CUDA packages hosted on the Nvidia repository are split into multiple subpackages, based on the library. For each library, you have the corresponding devel subpackage with the headers, the unversioned library symlink and the static library. Here, they were divided in one libs, one big extra-libs, one static and one devel subpackage for everything. Since I’m planning to enable CUDA/NVCUVID encoding/decoding in FFmpeg (I’m actually waiting to the dynamic loader patches to land in the 3.2 branch before enabling that) there should be a way to install just what is required by those functions and not the whole CUDA toolkit set of libraries.

So now, all the libraries are split into subpackages, much like in the original Nvidia CUDA repository. This allows you to install and build software relying on specific components without the need to install all the CUDA toolkit just to satisfy a library dependency. With the new packaging organization, the original cuda-devel and cuda-extra-libs will pull in all the specific subpackages giving you the same situation you are accustomed to. Also, for the same reason, static libraries have been included in each respective devel subpackage.

Example, just with the basic tools:

$ sudo dnf install cuda
Last metadata expiration check: 0:00:20 ago on Sun Oct 23 13:11:01 2016.
Dependencies resolved.
================================================================================
 Package           Arch         Version               Repository           Size
================================================================================
Installing:
 cuda              x86_64       1:8.0.44-4.fc24       fedora-nvidia        95 M
 cuda-cufft        x86_64       1:8.0.44-4.fc24       fedora-nvidia        97 M
 cuda-curand       x86_64       1:8.0.44-4.fc24       fedora-nvidia        38 M
 cuda-libs         x86_64       1:8.0.44-4.fc24       fedora-nvidia       6.4 M

Transaction Summary
================================================================================
Install  4 Packages

Total size: 236 M
Installed size: 469 M
Is this ok [y/N]:

The basic tools along with all the libraries (note that the NVML headers are included):

$ sudo dnf install cuda-devel
Last metadata expiration check: 0:10:00 ago on Sun Oct 23 13:11:01 2016.
Dependencies resolved.
================================================================================
 Package                 Arch       Version             Repository         Size
================================================================================
Installing:
 cuda                    x86_64     1:8.0.44-4.fc24     fedora-nvidia      95 M
 cuda-cublas             x86_64     1:8.0.44-4.fc24     fedora-nvidia      21 M
 cuda-cublas-devel       x86_64     1:8.0.44-4.fc24     fedora-nvidia      38 M
 cuda-cudart             x86_64     1:8.0.44-4.fc24     fedora-nvidia     131 k
 cuda-cudart-devel       x86_64     1:8.0.44-4.fc24     fedora-nvidia     659 k
 cuda-cufft              x86_64     1:8.0.44-4.fc24     fedora-nvidia      97 M
 cuda-cufft-devel        x86_64     1:8.0.44-4.fc24     fedora-nvidia      73 M
 cuda-cupti              x86_64     1:8.0.44-4.fc24     fedora-nvidia     1.2 M
 cuda-cupti-devel        x86_64     1:8.0.44-4.fc24     fedora-nvidia     213 k
 cuda-curand             x86_64     1:8.0.44-4.fc24     fedora-nvidia      38 M
 cuda-curand-devel       x86_64     1:8.0.44-4.fc24     fedora-nvidia      60 M
 cuda-cusolver           x86_64     1:8.0.44-4.fc24     fedora-nvidia      23 M
 cuda-cusolver-devel     x86_64     1:8.0.44-4.fc24     fedora-nvidia     4.1 M
 cuda-cusparse           x86_64     1:8.0.44-4.fc24     fedora-nvidia      23 M
 cuda-cusparse-devel     x86_64     1:8.0.44-4.fc24     fedora-nvidia      23 M
 cuda-devel              x86_64     1:8.0.44-4.fc24     fedora-nvidia     1.6 M
 cuda-libs               x86_64     1:8.0.44-4.fc24     fedora-nvidia     6.4 M
 cuda-npp                x86_64     1:8.0.44-4.fc24     fedora-nvidia      91 M
 cuda-npp-devel          x86_64     1:8.0.44-4.fc24     fedora-nvidia      47 M
 cuda-nvgraph            x86_64     1:8.0.44-4.fc24     fedora-nvidia     4.6 M
 cuda-nvgraph-devel      x86_64     1:8.0.44-4.fc24     fedora-nvidia      12 k
 cuda-nvml-devel         x86_64     1:8.0.44-4.fc24     fedora-nvidia      41 k
 cuda-nvrtc              x86_64     1:8.0.44-4.fc24     fedora-nvidia     6.6 M
 cuda-nvrtc-devel        x86_64     1:8.0.44-4.fc24     fedora-nvidia      16 k

Transaction Summary
================================================================================
Install  24 Packages

Total size: 655 M
Installed size: 1.4 G
Is this ok [y/N]:

The nvidia-driver-NVML-devel package, which was including the NVML header (for libnvidia-ml.so) has now been made obsolete by the new headers, which are now part of CUDA 8. So the cuda-nvml-devel package will take care of that. Again, this is the same as in the Nvidia repository. Everything that was requiring the NVML header now refers to that package instead of the previous one. I will leave it for a few releases like that and then I will remove the Obsolete/Provides tags from the various SPEC files.

The header is also required for building the latest nvidia-settings from the 375.10 source, this has been taken into account making the CUDA package buildable on i686 but generating only the cuda-nvml-devel subpackage.

Extra stuff

In addition to the libraries bundled in the CUDA toolkit, also the cuDNN library for distributed neural networks is included in the repository.

As usual, you are welcome to open bugs / request stuff / comment on the GitHub repositories.

GStreamer plugins for CentOS/RHEL 7, MPV and Fedora 25 repositories

The Multimedia repository now provides GStreamer (1.0) plugins for Bad, Ugly, libAV and VA-API plugin bundles with all options enabled for CentOS/RHEL 7. As per the Fedora ones, these are split into the following GStreamer runtime packages:

  • gstreamer1-plugins-bad
  • gstreamer1-plugins-ugly
  • gstreamer1-plugins-vaapi
  • gstreamer1-plugins-libav
  • gstreamer1-plugins-bad-fluidsynth (pulls in the whole FluidSynth distribution)

They all have an Epoch of “1”, to avoid any upgrade issue. Like for FFMpeg, I’ve tried to enable all the supported plugins out of the box. The “bad” package actually obsoletes the “bad-free”, “bad-nonfree” and “openh264” Gstreamer plugin packages. As such, they play nicely when enabling OpenH264 support on Firefox.

Apart from this, 99% of the Fedora 25 packages are now available, Fedora 24 and Fedora 25 repositories now have MPV in them.

Next steps

Next steps: