Nvidia driver, CUDA tools and libraries

Oh no, another Nvidia driver repository? Why?

This driver reflects my personal view for the way the driver should be packaged for Fedora and CentOS/RHEL. It’s somewhat different from ELRepo repositories for RHEL/CentOS and from RPMFusion packages for Fedora.

Repository installation

To install the repository on a supported Fedora distribution, run as root the following command:

dnf config-manager --add-repo=http://negativo17.org/repos/fedora-nvidia.repo

To install the repository on CentOS/RHEL:

yum-config-manager --add-repo=http://negativo17.org/repos/epel-nvidia.repo

Starting from Fedora 25, the Nvidia software packages are available for installation by default also in Gnome Software.


Please note that the driver will show up only if your system matches one of the PCI ID supported by the driver. Otherwise, only the other Nvidia programs (mostly for CUDA development) will show up in the software center.

What’s different?

First of all the packaging is a lot simplified; more stuff is compiled from source, smaller packages and more options. This packages try to comply as maximum to the Fedora Packaging Guidelines; which means they have debuginfo packages, default Fedora’s GCC compile time options (where possible) and standard locations for binaries, data and docs.

What follows below, is a detailed explanation of all the “differences” from the various Nvidia driver packages that I was able to spot on the web and a detailed description on how to install components, etc.

Nvidia drivers


  • nvidia-settings, nvidia-persistenced, nvidia-xconfig and nvidia-modprobe are compiled from source.
  • All RPM filters except for GL and OpenCL libraries have been removed, so there is no weird dependency option in the SPEC file. RPM pulls in all correct requirements on its own. This is to avoid pulling in the Nvidia drivers instead of the Mesa libraries or in place of the new open source OpenCL support that’s in Fedora.
  • Simplified packaging with much simpler and readable SPEC file.
  • Dependency on libva-vdpau-driver. So in Totem, or any other libVA supported application you can benefit from VDPAU acceleration.
  • Sources are generated with a script and inserted individually in the various packages; so it can be easily reproduced just by changing the version and rerunning the script.
  • nvidia-xconfig is not required on anything that uses the modular X.org directives, as it writes too much in the configuration file (keyboards, monitors, etc.) and the required entries should be written in separate configuration files under /etc/X11/xorg.conf.d. The package is still available as it’s required to speed up some configuration like multi-monitor setups with SLI Mosaic enabled from the command line, but not installed by default.
  • The NVIDIA OpenGL-based Framebuffer Capture (NvFBCOpenGL) libraries (NvFBC and NvIFR) are private APIs that are only available to NVIDIA approved partners for use in remote graphics scenarios (i.e. Steam In-Home Streaming hardware encoding); so they are packaged in another small package called nvidia-driver-NvFBCOpenGL.
  • The nvidia-settings package now builds the external libXNVCtrl.so library that can be used to control the graphic cards through the NV-CONTROL extension. This library updates the old and obsolete one in Fedora based on drivers version 165.
  • Starting from version 343.13, the nvidia-settings binary is compiled with GTK3 instead of GTK2 on Fedora and RHEL/CentOS 7+.
  • The driver can be installed separately from the nvidia-settings utility, so if you simply want a working driver and do not care about details, your experience should be as close as possible to the one with open source drivers.


  • ELRepo ships 32 bit compatibility libraries in a separate package with x86_64 as the architecture and “32bit” in the name. 32 bit libraries should be like in RPMFusion, with an i686 package installable in parallel with the x86_64 one. There are no other packages in the distribution that are built for x86_64, with “32bit” in their name that contain i686 binaries (!), so Nvidia drivers should not be an exception. So no separate “32bit.x86_64” package for 32 bit libraries also on CentOS/RHEL; just install nvidia-driver-libs.i686.
  • Versions are not hidden; all packages have the same driver version.
  • No alternatives system, only the latest version which integrates CUDA support is available. For older releases nouveau works great; and anything below a GeForce 8xxx it’s in my opinion too low end to play anything modern. And Quake 3 and Doom 3 work greatly with nouveau, so that’s not a case!
  • The CentOS/RHEL repository contains the “Long Lived Branch version” where less changes occur; while Fedora repositories contains the “Short Lived Branch version”. Beta CentOS/RHEL and Fedora’s rawhide repositories will contain the “Beta Branch version”

CUDA support

  • CUDA libraries/tools for the driver are split into subpackages. There’s no need to install all the CUDA libraries and tools on a system that has only one adapter and is used for occasional gaming or for simple office use. This can save ~120 MB worth of installed libraries. nvidia-persistenced falls in this category as it’s not needed on a normal laptop or gaming system.
  • Complete packaged CUDA stack has been added for all supported distributions, all the packages provide/require/obsolete the relevant packages in the Nvidia CUDA repository; so you can enable this repository along with the official Nvidia CUDA one (x86_64 systems only).

Kernel modules

  • Multiple choice of kernel module packages; akmod (RPMFusion) for Fedora and binary kmod (Kernel ABI whitelists) for CentOS/RHEL. In addition to this, on both distributions dkms packages are available. This way all cases and personal preferences are covered for both distributions.
  • Starting of drivers version 331.17, the kernel module packages contain the main Nvidia kernel module (nvidia.ko) but also the Unified Memory kernel module.
  • Support for multiple kernel modules has been deprecated in recent driver versions (they are available up to 352.xx); but both akmod and dkms packages can be configured to build the additional modules instead of the single one, so you can still choose your preferred method.
  • Starting from Nvidia driver version 334.16, the Nvidia DDX driver for X can also rely on the nvidia-modprobe command in the system to create devices and set permissions, so the new optional package has been added.
  • The nvidia module has a soft dependency on the nvidia-uvm module, making sure the module is loaded when installing the nvidia-driver-cuda package, but making sure that these modules are not included in the initrd (thing that would happen with systemd configuration (module-s-load.d). UDev rules make sure the module has proper permissions.
  • On Fedora, the kernel modules are compressed with XZ, like all the other kernel modules.

Default configuration

  • Dracut options are depending on the distribution; so no more “vga=normal is an obsolete option” at boot. Each distribution gets its own specific GRUB options for booting.
  • 96 DPI is written in the default xorg.conf config file. Why? Gnome 3 by defaults hard-codes a 96×96 DPI resolution, most of the free drivers do (intel, nouveau, etc.) as the EDID is almost never reliable (please see the excellent Adam’s Jackson post where he explains this). As an example, if you install the Nvidia drivers on a RHEL/CentOS 6 laptop where you used to have nouveau installed (96 DPI hardcoded), the fonts gets 90% of the time supersize and ugly as Gnome 2 and the Nvidia driver do not hard-code 96 DPI like Gnome 3.
  • Make X.org NVIDIA Files section to be loaded latest in case there are other packages providing a custom Files section.
  • Starting from Fedora 21, all driver X.org configuration can be managed by simply adding/removing X.org configuration snippets in /etc/X11/xorg.conf.d.
  • Use new OutputClass directive on Fedora 21 X.org server 1.16 (and later) to load the driver and do not rely on an edited /etc/X11/xorg.conf file. This also removes editing of the xorg.conf file from the package scriptlets. This does not hardcode the 96 DPI resolution.
  • Add the IgnoreABI directive by default on Fedora rawhide builds.

Kernel modesetting and Wayland support

Kernel mode setting on the nvidia-drm module has been disabled by default for various reasons. First of all, Wayland support in the drivers require a patched Wayland which has been refused upstream, and then the driver itself does not expose an FB driver for the console, so you won’t see any difference in the terminal output, you will still be limited to VGA.

There is a proposal for sorting everything out at XDC 2016 for hardware vendors that require to expose extensions for the drivers.

The Wayland libraries are still included in the Fedora builds, as all the dependencies are there but they are not used. On CentOS/RHEL 7 packages, they are not included as this would result in missing dependencies.

Vulkan support

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.

Distribution and Nvidia driver version support

Here is a rundown of Nvidia supported drivers and options split by distribution. Basically, CentOS/RHEL will always get a Long Lived branch release if possible, Fedora always a Short Lived branch release, and unreleased distributions will always get a Beta driver.

Operating systemel6 / el7f24 / f25f26
Driver branchLong LivedShort Lived
Long Lived
Short Lived
Long Lived
Driver version375.39378.13378.13

Basic nvidia driver:

CUDA libraries and tools:

OpenGL Framebuffer Capture:

Nvidia tools:

nvidia-healthmon (x86_64)
nvidia-validation-suite (x86_64)

Binary kernel
modules (kABI):

DKMS kernel

aKMOD kernel

32 bit compatibility on x86_64:


GLVND libraries

VDPAU libraries


Sample installation

Here is an example. 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
 dkms-nvidia          x86_64   2:375.10-1.fc25                        fedora-nvidia   6.4 M
 libglvnd             i686     1:0.2.999-3.20161017gita813b56.fc25    fedora-nvidia   103 k
 libglvnd             x86_64   1:0.2.999-3.20161017gita813b56.fc25    fedora-nvidia   105 k
 libglvnd-gles        i686     1:0.2.999-3.20161017gita813b56.fc25    fedora-nvidia    29 k
 libglvnd-gles        x86_64   1:0.2.999-3.20161017gita813b56.fc25    fedora-nvidia    28 k
 libglvnd-glx         i686     1:0.2.999-3.20161017gita813b56.fc25    fedora-nvidia   114 k
 libglvnd-glx         x86_64   1:0.2.999-3.20161017gita813b56.fc25    fedora-nvidia   110 k
 libglvnd-opengl      i686     1:0.2.999-3.20161017gita813b56.fc25    fedora-nvidia    39 k
 libglvnd-opengl      x86_64   1:0.2.999-3.20161017gita813b56.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-1.fc25                        fedora-nvidia   3.1 M
 nvidia-driver-NVML   x86_64   2:375.10-1.fc25                        fedora-nvidia   397 k
 nvidia-driver-libs   i686     2:375.10-1.fc25                        fedora-nvidia    15 M
 nvidia-driver-libs   x86_64   2:375.10-1.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                        fedora          1.5 M
 vulkan               x86_64                        fedora          1.4 M
 vulkan-filesystem    noarch                        fedora          8.0 k
Transaction Summary
Install  20 Packages
Total download size: 43 M
Installed size: 184 M
Is this ok [y/N]:

As you can see, this system has dkms enabled kernel module and libraries for running 32 bit applications. The amount of data to download for the drivers is really small compared to packages that contain CUDA libraries and tools. All packages have an higher Epoch set; so they should never be upgraded on your system when you enable this repository along the RPMFusion or ELRepo ones.

Package installation

If you are booting the system in UEFI mode; as a prerequisite to installing any external module (not built into the kernel package), you have to disable UEFI Secure Boot in the system configuration. All modules contained in the kernel package are signed with keys that are generated during build and deleted when packaging. If you want to preserve Secure Boot, you need to sign the modules yourself and import the keys into your hardware module. Doing so is out of scope here; if you need a decent guide just follow Red Hat’s guide for signing kernel modules.

First of all remove all the Nvidia drivers you might have on your system due to RPMFusion, ELRepo, or the Nvidia CUDA repository. The packages should already take care of this for you, as they should be completely compatible; but better be safe than sorry. This is usually accomplished with the following root command:

yum -y remove \*nvidia\*

Then, to install the Nvidia driver and its control panel utility in CentOS/RHEL with the binary kABI (Kernel ABI whitelist) module (this is the default on CentOS/RHEL), perform the following command:

yum -y install nvidia-driver nvidia-settings

To do the same in Fedora, perform the following command:

dnf -y install nvidia-driver nvidia-settings kernel-devel

Requirement on kernel-devel is 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.

Specific driver installations

For both Fedora and CentOS/RHEL distributions it’s possible to install additional packages and / or variant of the basic kernel modules. This paragraph contains some examples. Make sure you have the RPMFusion repository enabled if you plan to use akmod kernel modules on Fedora or EPEL if you plan to use DKMS modules on CentOS/RHEL.

akmod kernel module variant (Fedora):

dnf -y install nvidia-driver kernel-devel akmod-nvidia

DKMS kernel module variant (Fedora/CentOS/RHEL):

yum/dnf -y install nvidia-driver kernel-devel dkms-nvidia

To add 32 bit libraries on a 64 bit system (for games or applications like Steam):

yum -y install nvidia-driver-libs.i686

Additional driver configuration to your system

To add additional configuration to your system, just create the /etc/X11/xorg.conf file if it does not exist (by default it exists only in Red Hat Enterprise Linux / CentOS 6 systems). For example:

Section "Device"
    Identifier  "Device0"
    Driver      "nvidia"
    Option      "NoLogo" "true"
    Option      "DPI" "96 x 96"
    Option      "SLI" "Auto"
    Option      "nvidiaXineramaInfoOrder" "DFP-0"
    Option      "metamodes" "GPU-a493fbbb-7d76-86a2-8764-d76d487a75a7.DVI-I-1: nvidia-auto-select +0+0, GPU-c02960a4-be28-d5ce-8b02-be04b5e2550b.DVI-I-1: nvidia-auto-select +1680+0"
    Option      "BaseMosaic" "on"

In this example we have 2 video cards with one monitor each, so we enabled SLI, Base Mosaic to have multi monitor support on SLI and make a layout with the second GPU monitor on the right of the first one. Also, we fix the DPI to 96×96, which is the hardcoded default in Gnome and in Open Source drivers.

Configuration for headless systems

Your system might only be used for CUDA development and not require the X server to be running the driver at all, so you might want to tweak the configuration a bit to make the system load (for example) the Intel driver as the main display and just the Nvidia driver for calculation. In this case, the Intel driver should load the modesetting driver, offload the rendering to the Nvidia driver and not use any monitor attached to the X server for the Nvidia driver.

So in this case, I would change /etc/default/grub to remove the nomodeset parameter to make the Intel KMS driver to load properly, regenerate the Grub config file, reboot and use this xorg.conf:

Section "ServerLayout"
    Identifier "layout"
    Screen 0 "intel"
    Inactive "nvidia"
Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "<BusID for NVIDIA device here>"
Section "Screen"
    Identifier "nvidia"
    Device "nvidia"
    Option "AllowEmptyInitialConfiguration"
Section "Device"
    Identifier "intel"
    Driver "modesetting"
Section "Screen"
    Identifier "intel"
    Device "intel"

An example of the above can also be read in the official documentation.

The device file /dev/nvidia0 is normally created when loading the Nvidia driver, so if the X driver is not loaded the device file fileis not created. You can use the nvidia-modprobe command that is in the package with the same name.
It contains a SUID binary that creates the device files and set the appropriate permissions when automatic device creation is not available. It is called directly by Nvidia libraries:

$ for i in $(rpm -ql nvidia-driver-libs.x86_64); do strings $i | grep nvidia-modprobe && echo $i; done

This requires some testing and adjustments with specifics to your setup, but is definitely possible to use the integrated Intel card and or rely on a system without X installed to run the CUDA components.



  • Previously in the repository was included the GPU Deployment kit. This was constructed with NVML (NVIDIA Management Library) headers, docs and samples from a separate tarball. The separate tarball was using a different version number than the drivers and was packaged in the nvidia-driver-NVML and nvidia-driver-NVML-devel packages. Installing these, the gpu-deployment-kit dependency provided by the CUDA repositories was preserved. Starting from CUDA version 8, the NVML header is provided by a CUDA subpackage (cuda-nvml-devel) and no longer provided as part of the GPU Deployment kit.
  • Along with NVML, the nvidia-healthmon and nvidia-validation-suite package is provided to monitor TESLA GPU clusters (x86_64 systems only). For whatever confusing reason, these are not part of the CUDA 8 release. I will leave them in the repository for a while before removing them.
  • Included is also the NVENC (Nvidia Encoder) header, docs and code samples. Again, this uses a different version than the drivers.
  • 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.
  • In addition to the libraries bundled in the CUDA toolkit, also the cuDNN library for distributed neural networks is included in the repository. See the table below for details.

Distribution and CUDA version support

Operating systemel6 / el7f23 / f24 / f25
CUDA branch/version8.0.448.0.44
CUDA cuDNN version5.15.1
Basic CUDA libraries/tools:

CUDA development:

(also i686)
Java GUI programs:

Documentation and samples


CUDA installations

To install just a runtime CUDA support (required for running CUDA enabled programs):

yum -y install cuda nvidia-driver-cuda

To install packages required for enabling CUDA development:

yum -y install cuda-devel

or, if you need to develop some application that requires multiple libraries:

yum -y install cuda-devel

A couple of examples. Just 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
 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
 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]:

An example where your CUDA application just uses the CUDA Runtime API and not the kernel runtime:

$ sudo dnf install cuda-cudart
Last metadata expiration check: 0:13:10 ago on Sun Oct 23 13:11:01 2016.
Dependencies resolved.
 Package           Arch         Version               Repository           Size
 cuda-cudart       x86_64       1:8.0.44-4.fc24       fedora-nvidia       131 k
Transaction Summary
Install  1 Package
Total size: 131 k
Installed size: 536 k
Is this ok [y/N]:

This will avoid you pulling in all the libraries as before just because you need a single library. This is useful for example for programs that leverage just some part of the CUDA toolkit, like the Nvidia Performance Primitives for image and signal processing in FFmpeg, and similar things.


Just open an issue to the specific package on GitHub.

705 thoughts on “Nvidia driver, CUDA tools and libraries

  1. Thanks for all of your efforts in creating these repositories.
    I just installed the drivers and cuda packages under Fedora 25.
    I just got a new Nvida 1070 card and the graphics work beautifully.

    However, the cuda applications are not recognizing the card.
    Could I be missing a configuration setting somewhere or a conflict from
    a file for my previous Nvidia GTX280 card?

    1. What do you mean by “not recognized”? Did you install the nvidia-driver-cuda package and reboot (it requires the nvidia-uvm module to be loaded).

      1. The problem was between the seat and keyboard. I had all of the cuda packages installed except nvidia-driver-cuda. it works now. Thanks.

  2. Thanks for the package! However, the akmod compile fails on me on a fresh new F26-alpha (kernel 4.11.0-0.rc5):

    X86_64/nvidia-drm/nvidia-drm-drv.c:682:31: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]

    .unload = nvidia_drm_unload,

    Do you know if any fix is incoming, or should I go back to F25?

  3. Running Fedora 25 Gnome. Do you save the nvidia settings as “nvidia.conf” or “nvidia-xorg.conf” in the /etc/x11 folder? Which one works? When I reboot the boxes are unchecked (ForceCompositionPipeline and Force Full Composition Pipeline).Thanks.

    1. It depends on what you need to do. If you just want to add an additional settings to the Device section then you might just edit /etc/X11/xorg.conf.d/10-nvidia.conf.

  4. Hi negativo,

    For some reasons, dkms seems unable to build with following result

    DKMS make.log for nvidia-378.13 for kernel 4.10.5-200.fc25.x86_64 (x86_64)
    Sun Mar 26 23:30:10 PDT 2017
    Makefile:19: /Kbuild: No such file or directory
    make: *** No rule to make target ‘/Kbuild’. Stop.

    kernel-devel is already installed as listed below
    $ dnf list installed *kernel* | grep 4.10.5-200
    kernel.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-core.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-devel.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-headers.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-modules.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-tools.x86_64 4.10.5-200.fc25 @updates-testing
    kernel-tools-libs.x86_64 4.10.5-200.fc25 @updates-testing

    Graphic card is Nvidia Geforce GTX 460v2

  5. I have Optimus Asus Geforce 930M enabled system on Fedora 25. I install your driver and Nvidia GPU is working fine along with “nvidia-smi” from CUDA packages, other options never worked correctly. Now my X11 is on Nvidia GPU, I can see glxgears and everything performing excellent.

    Now when I use my laptop on Battery power, how do I switch to Intel Integrated Graphics on your drivers, switcheroo?

    Any pointers would be appreciated. Thanks in Advance.

    BTW, Great Work! on Fedora 25, nothing else works. Yours is just perfect.

    1. Now when I use my laptop on Battery power, how do I switch to Intel Integrated Graphics on your drivers, switcheroo?

      Unfortunately not, that’s limited by Nvidia design. With the Nvidia solution, both chipsets are always on unfortunately. The switcheroo part disappears the moment the nvidia kernel module is loaded. With Optimus enabled, the rendering is always done by the Nvidia chipset, so you can not switch off the discrete card if you don’t use it.

      1. Let me explain, I was on Ubuntu Optimus configuration the other day, you can prime-select to Intel, log out and log back in, and Intel drives the display, the Nvidia module is unloaded. I was looking for a similar solution in Fedora.

        For example, when I want to run CUDA apps, I will switch to Nvidia and system will load Nvidia Modules, when I just want lightweight usage, Intel GPU is fine. Eventhough Nvidia GPU is “powered on”, it will not perform any computation…

        I don’t want to turn either of them off…

        1. There is none like that. That is unsupported by both Nvidia and upstream X.org components, it does switch GL libraries on the fly etc. The correct implementation requires GLVND support (so GL libraries on demand) and plain RandR support with Sink offloading. The Ubuntu implementation uses an acpi module derived from Bumblebee that triggers a specific ACPI call per hardware module.

          In my latest job that very thing would actually break some systems up to the point that they required a hard reboot to revive the Nvidia card. Even going in the bios settings would not allow you to bring the card back to life.

          1. Thanks for the excellent info. Yes ubuntu has Nvidia Prime fork which allows to do so. I found this project to claim the same functionality, I haven’t tried it. I will give it a shot & will update.


            Agreed, the enterprise systems shouldn’t toggle this thing on the fly. This is something which concerns more to personal user.

  6. Recent F26 (branched) mesa-libGL update is conflicting with /usr/lib64/libGLX_indirect.so.0 from nvidia-driver-libs – you’re probably already aware. Is this going to require a package update?

    1. Nevermind – I see the post below. I’m guessing the update hasn’t been pushed for devel repos yet. 🙂

Leave a Reply