CUDA 9.0, cuDNN 7.0 and Wayland support in Fedora 27

slaanesh CentOS, CUDA, Fedora, Nvidia, Repositories, RHEL

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.

39 thoughts to “CUDA 9.0, cuDNN 7.0 and Wayland support in Fedora 27”

  1. Hello,

    Thank you for all the work you’ve done here on this website and providing the repositories. I use your Spotify build every day at work and it makes the day(s) much better.

    I just have a few questions regarding the current state of NVIDIA + Intel iGPU and Fedora. It’s a bit confusing and I’m having a lot of trouble finding clear concise answers so I hope that you can shed some light.

    System:
    I have a ThinkPad running Fedora 27 (Workstation w/ Wayland default). This ThinkPad has a Quadro K1100M and a “4th Gen Core Processor iGPU”. lsmod indicates that the drivers are used: i915 and nouveau. I have never gone out of my way to install any graphics drivers or anything, so I think these are what was loaded in by default.

    Basically, what I want to do is optimize this laptop for battery life, but I want to keep the option of using the dedicated GPU for some programs I need to use, like Paraview. So according to one of your post, I should use the “OSS Stack” which I think I am already using right now, by default.

    The problem is that the following directory doesn’t exist for me:

    /sys/kernel/debug/vgaswitcheroo/

    Is this because I do not use the VGA port, but the MiniDP/Thunderbolt port? When I right click on an app, I don’t get the option to “launch with dedicated GPU”.

    Reply

  2. Not working anymore with retpoline and latest kernel :
    nvidia: version magic ‘4.14.15-300.fc27.x86_64 SMP mod_unload ‘ should be ‘4.14.15-300.fc27.x86_64 SMP mod_unload retpoline ‘

    Reply

  3. HI!
    I have installed Fedora 27 Workstation, your’s Multimedia repo, nvidia and cuda, and Blender Cuda. Unfortunately Blender is not working (Cycles rendering, which is based on Cuda). I can see CUDA device in Blender however I can not render. Blender gives me this:

    “CUDA kernel compilation failed, see console for details.”

    I have installed this:
    cuda-1:9.1.85-2.fc27.x86_64
    nvidia-driver-cuda-2:387.34-1.fc27.x86_64
    nvidia-driver-2:387.34-1.fc27.x86_64

    Console:

    blender
    Read prefs: /home/Lew/.config/blender/2.79/config/userpref.blend
    X server found. dri2 connection failed!
    DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
    Assuming 131072kB available aperture size.
    May lead to reduced performance or incorrect rendering.
    get chip id failed: -1 [22]
    param: 4, val: 0
    X server found. dri2 connection failed!
    DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
    Assuming 131072kB available aperture size.
    May lead to reduced performance or incorrect rendering.
    get chip id failed: -1 [22]
    param: 4, val: 0
    cl_get_gt_device(): error, unknown device: 0
    X server found. dri2 connection failed!
    DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
    Assuming 131072kB available aperture size.
    May lead to reduced performance or incorrect rendering.
    get chip id failed: -1 [22]
    param: 4, val: 0
    X server found. dri2 connection failed!
    DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
    Assuming 131072kB available aperture size.
    May lead to reduced performance or incorrect rendering.
    get chip id failed: -1 [22]
    param: 4, val: 0
    cl_get_gt_device(): error, unknown device: 0
    X server found. dri2 connection failed!
    DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
    Assuming 131072kB available aperture size.
    May lead to reduced performance or incorrect rendering.
    get chip id failed: -1 [22]
    param: 4, val: 0
    cl_get_gt_device(): error, unknown device: 0
    CUDA version 9.10 detected, build may succeed but only CUDA 8.0 is officially supported.
    Compiling CUDA kernel …
    “nvcc” -arch=sm_20 –cubin “/usr/share/blender/scripts/addons/cycles/source/kernel/kernels/cuda/kernel.cu” -o “/home/Lew/.cache/cycles/kernels/cycles_kernel_sm20_7676DB34044E34BC890EDA27E229E638.cubin” -m64 –ptxas-options=”-v” –use_fast_math -DNVCC -D__KERNEL_CUDA_VERSION__=91 -I”/usr/share/blender/scripts/addons/cycles/source”
    nvcc fatal : Value ‘sm_20’ is not defined for option ‘gpu-architecture’
    CUDA kernel compilation failed, see console for details.

    Refer to the Cycles GPU rendering documentation for possible solutions:
    https://docs.blender.org/manual/en/dev/render/cycles/gpu_rendering.html

    Error: CUDA kernel compilation failed, see console for details.

    Please help.

    Best regards,
    P.

    Reply

  4. Hi
    I’m trying to build dlib (dlib.org) with your CUDA 9.0 packages on Fedora27,
    but I stuck at the cuda_test_build which is part of the cmake script of dlib. Which produces the following output:

    sudo make
    [ 50%] Building NVCC (Device) object CMakeFiles/cuda_test.dir/cuda_test_generated_cuda_test.cu.o
    nvcc fatal : Path to libdevice library not specified
    CMake Error at cuda_test_generated_cuda_test.cu.o.cmake:279 (message):
    Error generating file
    /root/dlib/cmake/dlib/cuda_test_build/CMakeFiles/cuda_test.dir//./cuda_test_generated_cuda_test.cu.o

    make[2]: *** [CMakeFiles/cuda_test.dir/build.make:510: CMakeFiles/cuda_test.dir/cuda_test_generated_cuda_test.cu.o] Error 1
    make[1]: *** [CMakeFiles/Makefile2:67: CMakeFiles/cuda_test.dir/all] Error 2

    Do you have any idea why the nvcc could produce that error?

    Reply

    1. Did you logout/reboot after installation? Your profile needs to have these variables:

      $ cat /etc/profile.d/cuda.sh
[ -x /usr/bin/nvcc ] && export NVVMIR_LIBRARY_DIR=/usr/share/cuda
[ -x /usr/libexec/cuda/open64/bin/nvopencc ] && export PATH=$PATH:/usr/libexec/cuda/open64/bin
[ -d /usr/include/cuda ] && export CUDA_INC_PATH=/usr/include/cuda
      Reply

  5. Thanks much for the packages!

    I thought I’d share some problems and solutions I found using them.

    I ran into two hitches using cuda-gcc to build TensorFlow 1.4.0: 1. had to hack rebuild libstdc++.a and libgomp.a to have PIC so that shared objects could be built with them, and 2. floatn.h needed to be hacked to not admit to having float128 (i.e. add something kinda like
    #if defined(CUDACC)
    #define __HAVE_FLOAT128 0
    #endif
    ) I could put this hacked floatn.h as /usr/lib64/gcc/6.4.0/include/bits/floatn.h so it will override the system version of the file under cuda-gcc.

    Running some TensorFlow-based code using the build hit a known bug when it loaded Linux Cuda’s libcusolver.9: the latter wants the symbol GOMP_critical_end supplied by libgomp.so.1, but doesn’t depend on that library. You can run the application with LD_PRELOAD=libgomp.so.1 or use patchelf –add-needed=libgomp.so.1 <libcusolver.so.9.0.176> to make a more permanent fix.

    From this I had some questions:

    Could there be PIC versions of libstdc++.a and libgomp.a in cuda-gcc / cuda-gcc-c++? If they sit alongside the static libraries there now, I’m not sure how the shared libraries being built in TensorFlow will find them, but…
    Should cuda-gcc have more differentiation in its paths so that a separate 6.4.0 compiler wouldn’t conflict, e.g. install into something like a /usr/lib64/gcc-cuda/6.4.0/… directory?
    Should cuda-gcc be configured –disable-libquadmath –disable-libquadmath-support to avoid the HAVE_FLOAT128 problem?

    Reply

      1. I think we should just make a note in the SPEC file and add the appropriate dependency so it is always installed. If you want commit access to cuda-gcc and cuda packages just ask!

        Thanks.

        Reply

    2. Hi Guy, thank you very much for your feedback. Indeed, the package cuda-gcc could see some improvements, that’s why I did not announce nor publish it on COPR (something along with https://copr.fedorainfracloud.org/coprs/slaanesh/compat-gcc-53/).

      Should cuda-gcc have more differentiation in its paths so that a separate 6.4.0 compiler wouldn’t conflict, e.g. install into something like a /usr/lib64/gcc-cuda/6.4.0/… directory?
      Could there be PIC versions of libstdc++.a and libgomp.a in cuda-gcc / cuda-gcc-c++? If they sit alongside the static libraries there now, I’m not sure how the shared libraries being built in TensorFlow will find them, but…

      I have some issues when making version specific runtime libs: https://github.com/negativo17/cuda-gcc/blob/master/cuda-gcc.spec#L87
      Basically the default search path for includes is not declared and I haven’t figured out how to populate it at build time. Also, we probably need to filter out the libraries in RPM to avoid breaking other packages.

      Should cuda-gcc be configured –disable-libquadmath –disable-libquadmath-support to avoid the HAVE_FLOAT128 problem?

      This can be done, SPEC file is here: https://github.com/negativo17/cuda-gcc
      We could also find a way to get rid of this, maybe: https://github.com/negativo17/cuda/blob/master/cuda.spec#L455-L457

      Reply

    3. I am having the same problem trying to compile the latest Knet package for julia that is on git hub..
      The released version only has a problem with the include files not being found. Are you trying to get your changes into the rpm packages? It is also looking for the 5.3.1 version of the files not the 6.5.0. Do you have any insights to offer?

      Reply

      1. I’m about to push a 6.4.0 package of cuda-gcc. This replaces compat-gcc-53 on Fedora 27. From now on, I will make a cuda-gcc compatible with the CUDA version available all the time. I did not announce it as I was still making the tests.

        Reply

  6. I’ve installed cuda9 on Fedora 27 via your repo. Thanks for organizing this resource.

    So far everything is going well, except I’m not finding the cutil library (this contains the code for the gpu high resolution timer). We should have a file like libcutil_x86_64.a

    Is this file missing in the repo or am I just not finding the right rpm?

    Reply

    1. You can disregard my question. I discovered that Nvidia removed the libcutil library some time ago and replaced it with the clock() and clock64() functions which are located in the cuda_runtime. I’m using the clock64() to instrument my kernel code and that’s working perfectly.

      Reply

  7. Hello, I cannot find compat-gcc64 or compat-gcc53 for Fedora 27 in your repositories at this time. For this I’m getting the following error message when trying to use nvcc:

    cc1plus: fatal error: cuda_runtime.h: No such file or directory
    compilation terminated.

    Reply

      1. I’m sorry, but could you clarify? I’ve just updated all my packages, by a dnf update. And then installed cuda-gcc manually.

        Here is the terminal output for nvcc and cuda-gcc now:

        [aneeshneelam@Titan squaring]$ nvcc gpu.cu -o gpu
        cc1plus: fatal error: cuda_runtime.h: No such file or directory
        compilation terminated.

        [aneeshneelam@Titan squaring]$ cuda-gcc gpu.cu -o gpu
        gpu.cu: file not recognized: File format not recognized
        collect2: error: ld returned 1 exit status

        Am I trying to compile this wrong? I thought the packages in the repositories set it up such that the include paths are already registered by the compiler(s)?

        Also, I cannot install cuda-samples:

        [aneeshneelam@Titan squaring]$ sudo dnf install cuda-samples
        Last metadata expiration check: 0:00:02 ago on Wed 29 Nov 2017 01:22:11 AM IST.
        Error:
        Problem: conflicting requests
        - nothing provides compat-gcc-53-c++ needed by cuda-samples-1:9.0.176-1.fc27.x86_64
        - nothing provides compat-gcc-64-c++ needed by cuda-samples-1:9.0.176-2.fc27.x86_64
        - nothing provides compat-gcc-53-c++ needed by cuda-samples-1:9.0.103-3.fc27.x86_64

        Hopefully this gets fixed soon.

        Thanks for your help!

        Reply

        1. Just an update, setting the include path manually now works with nvcc. It didn’t before installing cuda-gcc.

          [aneeshneelam@Titan squaring]$ nvcc -I /usr/include/cuda/ gpu.cu -o gpu
          [aneeshneelam@Titan squaring]$ ls
          cpu cpu.c gpu gpu.cu

          Reply

      2. Thank you for all of your work in setting up these packages for Fedora 27,
        Could you supply some guidance on how to get the cuda samples to compile?
        I get this error:
        error: identifier “__builtin_addressof” is undefined
        and then a string of errors starting with :
        instantiation of

        Reply

        1. I found that installing the conveniently nearby cuda-gcc, cuda-gcc-c++, and (lesser need) cuda-gcc-fortran rpms helped out with that (mentioned by Aneesh above).

          Reply

          1. You may need to invoke “HOST_COMPILER=cuda-g++ make” or “HOST_COMPILER=cuda-gcc make” to have nvcc find these compat 6 compilers.

  8. A fresh install of fedora 27 beta and the akmod-nvidia package leaves the following in /var/cache/akmods/akmods.log:

    2017/11/02 21:57:05 akmods: Checking kmods exist for 4.13.10-300.fc27.x86_64
    2017/11/02 21:57:05 akmods: Files needed for building modules against kernel
    2017/11/02 21:57:05 akmods: 4.13.10-300.fc27.x86_64 could not be found as the following
    2017/11/02 21:57:05 akmods: directories are missing:
    2017/11/02 21:57:05 akmods: /usr/src/kernels/4.13.10-300.fc27.x86_64/
    2017/11/02 21:57:05 akmods: /usr/lib/modules/4.13.10-300.fc27.x86_64/build/
    2017/11/02 21:57:05 akmods: Is the correct kernel-devel package installed?

    I discovered that the kernel-devel package for the 4.13.10 kernel version is NOT installed, only the 4.10.9 version is installed.

    I solved this by downloading the right package at the following URL and install it manually:

    https://koji.fedoraproject.org/koji/buildinfo?buildID=991436

    After a reboot the akmods.log file reads:

    2017/11/02 22:09:30 akmods: Checking kmods exist for 4.13.10-300.fc27.x86_64
    2017/11/02 22:09:30 akmods: Building and installing nvidia-kmod
    2017/11/02 22:09:30 akmods: Building RPM using the command ‘/sbin/akmodsbuild –target x86_64 –kernels 4.13.10-300.fc27.x86_64 /usr/src/akmods/nvidia-kmod.latest’
    2017/11/02 22:11:18 akmods: Installing newly built rpms
    2017/11/02 22:11:18 akmods: DNF detected
    2017/11/02 22:11:24 akmods: Successful.

    Reply

  9. Hello Slaanesh,

    there seems to be an issue with the fedora-multimedia updates for f26 from 2017-10-23:
    “gstreamer1-plugins-bad-1:1.12.3-2.fc26.x86_64” needs “libQt5Core.so.5(Qt_5.9)(64bit)”, which cannot be resolved, probably because f26 is still on qt 5.7. What can I do to resolve this? Thanks a lot.

    Reply

  10. Unfortunately, it seems I can only run Wayland under llvmpipe. X still seems to be working fine, but I can’t get Wayland to use nVidia. I’ve tried disabling selinux at one point, but it didn’t seem to change anything.

    Am I wrong in thinking it should just work under 27? Should I be able to simply install the driver and have it work, or is there another step required?

    Reply

  11. Just upgrade to Fedora 27 beta with neweast nvidia driver from the repo here, I (seems also) encounter the problem that GDM just crashed that only an Logout button showed for me, while it goes fine if nouveau is driving the display. It’s interesting that, after several tries, I found the GDM could be launched if SELinux is disabled.
    By the way, still, my session type is X11 rather than wayland, with nvidia-drm.modeset=1.

    Reply

    1. It seems to be an SELinux issue, this should temporarily fix it:

      ausearch -c 'gnome-session-c' --raw | audit2allow -M mygnomesession.c
semodule -X 300 -i mygnomesession.c.pp

      This is what is in audit.log:

      allow xdm_t xserver_misc_device_t:chr_file map;
      Reply

  12. On my side, i have some issues with F27 beta after the upgrade… I can’t launch GDM without an error message “Oh no something has gone wrong”. I am obliged to do alt + F2 and run a startx for everything to work. Under nouveau everything works. I have blocked wayland in the gdm configuration. i had no problems with the negativo drivers under F26.

    Reply

  14. apparently it’s not just me (it came out in other comments as well) but your beautiful work/repos aren’t usable in some parts of the world, DNF shuts itself complaining for low downloading speeds (below 5Kb/s). Never had any problems with other repos. Such a pity. Any idea? thanks for yiur work PS may I suggest you to start a survey on the issue?

    Reply

Leave a Reply