Category: Nvidia

CUDA 8, cuDNN, Nvidia drivers and GNOME Software metadata

slaanesh 48 Comments

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

slaanesh 7 Comments

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:

Fedora 24 and CentOS/RHEL 7 repositories

slaanesh 23 Comments

Fedora 24 repositories have been available for quite some time now, but here is the official statement that everything should be supported out of the box.

As part of the repository availability, I would like to say that starting from Fedora 24, the repositories are self-sustained and do not require RPMFusion to be enabled. I try to preserve compatibility between the two, so if you step into any problem just open an issue to the specific package on Github, send me an email or drop a message in the comment section of the various pages. Please note that “compatible” means that actually you shouldn’t get any conflict when installing packages, and not that I will not overwrite/obsolete the packages provided in the other repositories.

CentOS/RHEL 7 repositories have been available stand alone since the beginning and do not require external repositories to be enabled. Again, if an RPMFusion (or whatever will be mainstream at the moment) CentOS/RHEL 7 repository will appear, I will try to be compatible with it.

Scope of support

My basic idea is to have what I’m using normally everyday as a package in Fedora, enabling software combinations that would be otherwise impossible to distribute in official repositories due to license/patent issues. This for example includes NVENC (Nvidia Encoder) FFMPeg enabled builds that I use almost everyday.

Being a daily CentOS/RHEL 7 user I also want to support the latest and gretest of the same software on that platform, which also means rebuilding some official CentOS/RHEL 7 packages like VP8/9, VDPAU and VA-API libraries.

Due to the various package builds being different (or simply containing newer software releases) from what the other repositories offer, I also try to be completely independent, you can basically install the operating system and just use my repositories.

Build system changes

The (internal at the moment) build system uses Github as its primary system for storing the package information. There is a Negativo17.org public organization where all the work goes, so if you want to look at the development or the SPEC files, just browse to Github. If you have an issue or proposed change as well, you’re welcome to open an issue or create a merge request in the specific package Git page.

Skype Web Pidgin plugin

skype

The Skype repository used to contain purple-skype for Fedora and CentOS/RHEL distributions which at the time required an installed Skype to work. Now, I helped a new Fedora contributor into integrating the newly developed Skype web plugin, which is based on the Skype web client. The package in Fedora obsoletes and provides correctly the skype4pidgin plugin and as such I don’t need to provide anything else in the repository.

The installation instructions have been updated to reflect this.

Skype is available only in 32 bit format, so on a 64 bit a 32 bit client will always be installed. Since the merging with MSN, the HTML welcome screen requires a 32 bit WebKit GTK build to start. This is not included in the 64 bit only CentOS/RHEL 7 repositories; so for this reason, if you are running CentOS/RHEL 7, it requires the multimedia repository to be enabled and have the dependency solved. This used to be self-contained in the Skype repository, but this is no longer feasible for me to mantain considering there is a different rebuild of WebKit GTK in the Multimedia repository.

Spotify Client

spotify-client

The Spotify repository used to contain FFMpeg for CentOS/RHEL distributions and a requirement on FFMpeg’s RPMFusion as a Fedora dependency. FFMpeg is no longer included in the CentOS/RHEL 7 repositories so the multimedia repository has to be enabled to have the dependency solved. As for Skype, this no longer feasible for me to mantain considering there is a different rebuild of WebKit GTK in the Multimedia repository.

Here as well the installation instructions have been updated to reflect the change.

aKMOD kernel module packages

The kernel binary module packages generated by aKMOD are now compressed with XZ, like in the original Fedora kernel packages that contain kernel modules. I’ve become a DKMS contributor, so, as time permits, I will add the same functionality to DKMS for Fedora distributions.

At the moment, this applies to Nvidia and X-Pad kernel modules.

Gstreamer plugins and multimedia libraries

The Multimedia repository now provides GStreamer (1.0) plugins for Bad, Ugly, libAV and VA-API plugin bundles with all options enabled. This is split into the following GStreamer runtime packages:

  • gstreamer1-plugins-bad
  • gstreamer1-plugins-ugly
  • gstreamer1-vaapi
  • gstreamer1-libav
  • gstreamer1-plugins-bad-fluidsynth (pulls in the whole FluidSynth distribution)
  • gstreamer1-plugins-bad-nvenc (x86_64 only, pulls in the Nvidia binary driver; and at the moment it does not work properly)

They all have an Epoch of “1”, due to the various reasons explained at the top. They are not yet available for CentOS/RHEL 7 due to time constraints; I will try to prepare them in the next weeks.

Fedora 24 OpenH264 repository

A note on the Fedora 24 OpenH264 repository. As described in its wiki page, there is an extra repository that can be enabled directly in Fedora 24 that allows you to install OpenH264, its relevant Gstreamer 1.0 plugin and a Mozilla plugin for Firefox. Following the same logic, at the moment the same Gstreamer 1.0 plugin is provided/obsoleted (in newer form) by the gstreamer1-pluings-bad package. There is a conflict for the OpenH264 binaries which I will address soon.

Updated multimedia and Nvidia driver packages

slaanesh 27 Comments

As many of you have noticed, there are big updates pushed in the repositories. Merging all of them into one big repository is still ongoing; but as part of it all builds now come from these git repositories:

https://github.com/negativo17

Feel free to create merge requests or ask access to them.

VLC

Both Fedora 23 and RHEL / CentOS 7 packages now host VLC with all plugins enabled, so this means you can listen/watch any kind of multimedia file on both distributions. Obligatory screenshot (CentOS 7):

centos-vlc

Of course you can also play Blu-Ray discs with it.

Gstreamer “bad” plugins

Fedora contains also Gstreamer “bad” plugins with all possible options enabled. Some statistics:

$ gst-inspect-1.0 | grep Total
Total count: 227 plugins, 1483 features

Packages for both “ugly” and “bad” plugins are coming for CentOS/RHEL 7 as well.

Updated multimedia packages

Also the update brings in quite a few updates on multimedia libraries (live555, FFMpeg, x265, dcadec, etc.).

Fedora 24 support

Fedora 24 support is coming, most of the packages have been rebuilt and all repositories will be available before the release. Starting from Fedora 24, you can enable all repositories with or without RPMFusion being enabled. This means I will try to maintain compatibility but you will not require to enable it.

Nvidia driver

The Nvidia driver has been updated to 364.19 on all supported Fedora releases. This brings in mode setting for the nvidia-drm module and Vulkan support. In the current state, mode setting works only in conjunction with a custom Wayland and the module does not provide an fb driver for the console. The Wayland patches have not been merged (and is not going very well on this side) and a KMS console is not there; so basically even enabling it just brings absolutely no difference to your experience. As such, modesetting is disabled.

It also brings instability to both my systems, so I guess it needs to mature some more before being usable. To enable mode setting, perform the following changes:

# echo "options nvidia-drm modeset=1" > /etc/depmod.d/nvidia.conf
# depmod -a
# reboot

To be more precise, some kernel command should be removed when the kernel module gets also a fb driver:

# grubby --update-kernel=ALL --remove-args='nomodeset gfxpayload=vga=normal'
# sed -i -e 's/nomodeset gfxpayload=vga=normal //g' /etc/default/grub

At the moment, those parameters are still added by the package as there is absolutely no benefit in enabling mode setting. As I said, you will reboot and get absolutely no difference.

As usual, let me know of any problems. I will be away for holiday for 3 weeks, so do not expect a prompt reply!

Converged multimedia repository with restricted codecs and binaries

slaanesh 2 Comments

As most of you have noticed, the HandBrake repository has been integrating more and more multimedia packages that are not related to HandBrake itself or to its supporting programs. The latest additions to it are the CUDA/FFMpeg enabled Blender package and some additional encoding options for FFMPeg.

This definitely puts a nail in the coffin of the “CUDA programs” repository that was previously treated as a separate repository. I’m not able to provide separate repositories for them as either you have a full blown multimedia collection with each component strictly tied to each other (Blender requires FFMPeg and Nvidia drivers, FFMpeg requires restricted multimedia libraries and Nvidia drivers, HandBrake requires the same restricted multimedia libraries of FFMPeg, etc.) or you just have the plain Fedora repositories with no license/patent encumbered options.

None of these packages can be distributed inside the main Fedora/RPMFusion repositories as they are presented here with current build options; mainly due to patent and licensing issues or simply because they are coupled with non open source software resulting in dubious licensed binaries.

Some of the packages might have hard dependencies on Nvidia components or libraries, while some other have a weak dependency on them. Whether you can enable support for those it’s usually just a matter of adding or not the Nvidia repository and the multimedia (HandBrake) repository at the same time.

Not all distributions are on par regarding features and packages, let’s say most of the development goes on to the latest Fedora release due to it being my daily desktop.

To install the CUDA enabled Blender, HandBrake, MakeMKV or the fully fledge FFMpeg binary just go to the appropriate page and follow the instructions.

I will probably also rename the repository into something more generic compared to what is currently called now; so suggestions are welcome!

Screenshot from 2015-12-11 19-20-27

Updated packages and new Samsung repository

slaanesh 5 Comments

As some of you may have noticed, a lot of updates and new stuff has been pushed.

Highlights from the updates

  • The Nvidia driver version 358.16 has been promoted as “Short Lived” for Fedora, and it has support for X.org Video ABI 20. So it is now the default for Fedora 21, 22 and 23.
  • Driver version 352.63 is the new “Long Lived” driver for RedHat/CentOS.
  • Both drivers have a fallback mechanism for the SELinux regression introduced in 358.09, so you don’t need anymore to disable SELinux for GDM refresh problems.
  • The legacy driver has been updated to 340.96, and this as well has been enabled for Fedora 23 as it also supports X.org 1.18
  • CDRtools after years of an alpha 3.01 has finally updated to… an alpha 3.02 😀
  • HandBrake has been updated to the very latest snapshot and is relying only on separate source tarballs that are not statically linked. Unfortunately some are of dubious licenses as usual. Please note that there are some issues with subtitle tracks embedded in Matroska files not being correctly interpreted.
  • The Nvidia NVML library and CUDA packages have seen some small update.
  • Steam has been updated to version 1.0.0.51 and has updated UDev rules for the Steam Controller. If you are one of the owners of such controller, you will find support out of the box. The same changes have also been pushed to the RPMFusion package.

New repository

There’s a new repository for Samsung printers, multifunction printers and scanners that carries the “Samsung Unified Linux Driver” for both the scanning and printing functions. Just by installing it and enabling the ports in the firewall should be enough to get every device running in no time. Refer to the appropriate page for details.

Fully fledged FFMpeg binaries

Also, due to popular request, there is now a custom built FFMpeg package that drops in as a replacement for RPMFusion ones and that enables linking and support for all the codecs/encoders/decoders that would result in an unredistributable binary. This is now available the HandBrake repository. The following codecs/encoders/decoders/transports have been enabled:

  • VP8 and VP9 de/encoding
  • WebP encoding
  • AAC (Fraunhofer, LibVO and other variants) de/encoding
  • OpenAL 1.1 capture support
  • BluRay reading
  • AMR-WB de/encoding
  • AMR-NB de/encoding
  • RTMP[E] support
  • H.264 encoding (OpenH264, Cisco variant)
  • OpenGL rendering
  • SSH transport
  • Fontconfig/fribidi text support

This sobstitutes the ffmpeg binary that was provided as part of the CUDA enabled programs, as it is now tied to all the other multimedia libraries available in this repository. The support for Nvidia H.264/H.265 hardware encoding/decoding is enabled here as well and the required packages are now installed through the use of RPM weak dependencies.

The package has a different Epoch so it is not overwritten by normal updates. The idea is to have all the possible codecs supported out of the box, so also expect HEVC kvazaar (H.265), Intel Quick Sync Video (H.265) hardware support through libmfx/mfx_dispatch, CIFS transport, and other stuff, as soon as I have more time.

The same repository will be used to host the CUDA and FFMpeg enabled Blender, as it makes no sense to have a separate repository for it. Either you have a full blown multimedia collection with each component strictly tied to each other, or you just have the plain Fedora repositories with no license/patent encumbered options.

Enjoy!

Fedora 23 packages now live

slaanesh 38 Comments

All the repositories have been updated for Fedora 23, so if you trigger an update, everything should update properly. CUDA enabled programs are still building.

A few notes:

  • HandBrake has been updated to a pre-release of 1.0 for Fedora 23. Updated x264/x265/FFmpeg libraries should give a speed bost to all encoding operations.
  • The Spotify 0.9.x repository has been removed. It will never receive updates anymore, and now the 1.x builds are on feature parity, including 32 bit support. If you haven’t upgraded, just do it now.
  • Nvidia drivers version 358.09 do not yet support X.org driver ABI 20, so you’re probably going to have some lock ups or random issues.
  • The SteamOS and X-Box replacement driver have been updated to the latest upstream.

Please let me know if you have any upgrade issue.

NVIDIA repository improvements

slaanesh 14 Comments

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.

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.0 enabled programs for Fedora 22

slaanesh 2 Comments

nv-cuda-2014header-updatedI’ve udpated the CUDA version in the Fedora 22 Nvidia repository, it now contains CUDA 7.0.28 along with the cuFFT 7.0.35 patch. Note that from this version, CUDA is x86_64 bit compatible only, so there are no more i386 packages. There is still the cudart library available for 32 bit, but I don’t think it’s worth packaging.

The packages hosted here should correctly upgrade and obsolete the ones in Nvidia’s own repository, so it should be possible to go straight from one version to the other, if you need.

The static libraries (according to packaging guidelines) have been placed in a cuda-static package, thus reducing by an order of magnitude the size of the packages containing libraries. The toolkit can of course be installed and used to create CUDA binaries on systems where there is no Nvidia adapter installed.

The Nvidia compiler (nvcc) throws an error if the GCC version detected is higher than 4.9 (Fedora 22 default is 5.1.1), but the removing the check makes the compiler run fine until you enable C++11 support. If you need to enable C++11 support you need to use a separate GCC, older than 5.x, for compilation. See this comment here for details.

As part of the update, the repository that contains CUDA enabled programs (Blender, CCMiner and NVENC enabled FFMpeg) has been updated for Fedora 22. This is completely optional, so you can have Nvidia packages on your system and still use RPMFusion’s FFMpeg and Fedora’s Blender. I’ve tried to submit Blender updates to the appropriate package maintainer but did not receive any answer.

I will rebase all distributions to CUDA 7.0 as soon as the next long lived driver release will be branched by Nvidia.

As always, feedback is welcome. If you have any issue or would request an enabled CUDA package to add to the repository, just write in the comments or write me an email.