Patrice Ferlet
Patrice Ferlet
Créateur de ce blog.
Publié le Apr 6, 2019 Temps de lecture: 7 min

Cuda et Tensorflow sur Fedora 29

L’un des points sensibles quand on veut travailler en machine learning avec TensorFlow, c’est l’installation et la gestion de version de CUDA - voici la marche à suivre que j’utilise depuis quelques temps et qui me permet de faire les choses bien.

J’utilise Fedora 29, et il fait bien l’avouer, l’installation de CUDA et des libs CuDNN sont franchement pas géniales si on se réfère à la documentation Nvidia. La récupération de la bonne version CUDA et le fait de devoir s’inscrire pour récuperer un tarball pour la librarie CuDNN est pas l’idée que je préfère… Bref !

Au détour d’une conversation sur le canal fedora-fr (IRC, sur freenode), Nicola Chanvet alias Kwizart me parle d’une section de RPM Fusion qui fait mon bonheur. Alors allons-y, lançons nous dans une installation propre de ce qu’il faut pour avoir les pilotes Nvidia, CUDAO 10, et les libs CuDNN nécessaires pour Tensorflow, mais aussi pour faire des rendus Blender rapides, ou encore jouer dans de bonnes conditions.

Étape 1, on dégage les vieilles libs pourries

C’est la phase la plus ennuyeuse, à faire si vous avez déjà installé des paqutes. Voilà comment j’ai fait:

# on vire cuda
sudo dnf remove cuda
sudo dnf remove cuda-*
sudo dnf remove $(sudo dnf list installed cuda*)
sudo dnf remove $(sudo package-cleanup --leaves | grep cuda)

Voilà, ça c’est fait.

Reste à nettoyer les déchets:

sudo rm -rf /usr/local/cuda /usr/local/cuda*

Ça fait du bien hein :)

Étape 2 (ou 1 pour certains) on installe les bon dépôts, les pilotes, etc…

Si vous n’avez pas encore RPM Fusion

Maintenant que vous avez nettoyé un peu, on peut passer à une installation cool.

Si ce n’est pas déjà fait, vous allez installé les dépôt RPM Fusion:

sudo dnf install \
   https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
   https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Installer le pilote nvidia

Si vous ne l’avez pas encore fait, on peut maintenant installer le pilote “nvidia” (propriétaire, c’est moche, mais pas le choix).

Avec ces dépôt, on peut installer les pilotes nvidia. Passez par akmod au lieu de kmod pour assurer une compilation du module lors des mises à jour du kernel, c’est selon moi bien plus sécurisant.

sudo dnf makecache
sudo dnf install akmod-nvidia

Là je vous conseille de redémarrer l’ordinateur.

Maintenant que le pilote nvidia est là, vous pouvez vérifier facilement si la carte est bien reconnue en tapant nvidia-smi dans un terminal:

nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 418.56       Driver Version: 418.56       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 106...  Off  | 00000000:02:00.0  On |                  N/A |
|  0%   42C    P8     5W / 120W |    111MiB /  3019MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      1795      G   /usr/libexec/Xorg                             39MiB |
|    0      1946      G   /usr/bin/gnome-shell                          69MiB |
+-----------------------------------------------------------------------------+

Bien, tout est là. On passe à CUDA et cuDNN.

Notez bien la version de CUDA, on va en reparler

Installer CUDA et cuDNN

C’est maintenant que vous allez installer les paquets qui changent tout pour TensorFlow, Blender, et certains jeux.

La documentation du site nvidia est vraiment pas claire, alors que dans les faits… c’est tellement plus simple de passer par une simple ligne d’ajout de dépôt à l’ancienne.

En se basant sur la page RPM Fusion, section “Machine Learning” comme me l’a indiqué Kwizart:

# on installe les dépôts cuda et machine learning de nvidia
sudo dnf install https://developer.download.nvidia.com/compute/cuda/repos/fedora29/x86_64/cuda-repo-fedora29-10.1.105-1.x86_64.rpm
sudo dnf install https://developer.download.nvidia.com/compute/machine-learning/repos/rhel7/x86_64/nvidia-machine-learning-repo-rhel7-1.0.0-1.x86_64.rpm

# puis les paquets:
sudo dnf install cuda
sudo dnf install libcudnn7 libcudnn7-devel libnccl libnccl-devel

Je vous préviens, CUDA prend presque 3.8Go sur votre disque, donc soyez prêt à attendre si vous avez une connexion internet compliquée. Mais en soit, enfin on évite une inscription sur le site Nvidia pour récupérer la lib CuDNN !

Et là, ne cherchez pas plus loin, on va avoir un problème

Ce qui va vous faire un peu mal… c’est que, à l’heure où j’écris ces lignes, TensorFlow 1.13 n’est pas compatible avec CUDA 10.1, mais CUDA 10.0 – et pour parfaire la crise, il faut aller récupérer le dépôt nvidia pour… Fedora 27. Sympa hein ?

En définitive, il faut installer une version antérieure de CUDA pour assurer la compatibilité avec TensorFlow… régulièrement…

Le plus simple, c’est de créer un fichier de dépôt à partir du premier, mais comme je voulais aussi changer le nom… voilà le fichier à créer:

sudo tee /etc/yum.repos.d/cuda-f27.repo << EOF
[cuda-old]
name=cuda-old
baseurl=http://developer.download.nvidia.com/compute/cuda/repos/fedora27/x86_64
enabled=1
gpgcheck=1
gpgkey=http://developer.download.nvidia.com/compute/cuda/repos/fedora27/x86_64/7fa2af80.pub
EOF

sudo dnf makecache

Et d’installer la version antérieure:

sudo dnf install cuda-10-0

Donc, à patir de maintenant, vous avez deux versions de CUDA sur votre poste, une 10.0 et une 10.1. Heureusement pour nous, CUDA s’installe dans /usr/local/, et sépare les versions en tant que telle en nommant les répertoires. Et c’est un lien sympbolique de /usr/loca/cuda sur un des répertoires qui active la version “par défaut”.

Cela veut dire que vous avez deux solutions:

  • soit vous forcez la variable LD_LIBRARY_PATH=/usr/local/cuda-10.0 avant de démarrer un shell python, jupyter ou ce que vous voulez…
  • soit vous modifiez le lien sympbolique:
    ln -sf /usr/local/cuda-10.0 /usr/local/cuda
    

Dans le second cas, vous allez donc changer la version par défaut pour tout le système. En soit ce n’est pas très grave, mais il faut le savoir.

Testons…

C’est bien beau d’avoir installé CUDA et CuDNN, mais il va falloir au moins vérifier que tout fonctionne. Ce que je vous propose est une simple session TensorFlow qui doit soit vous péter une erreur limite insultante, soit vous donner le sourire.

La méthode la plus facile que j’ai à vous proposer est la suivante:

python3 -mvenv /tmp/tftest
source /tmp/tftest/bin/activate
pip3 install -U tensorflow-gpu
python3
>>> import tensorflow as tf
>>> tf.Session()

Vous devez alors voir une ligne dire que le GPU est présent et utilisable, chez moi ça donne quelque chose du genre (en supprimant des lignes qui ne vous intéressent pas):

2019-04-06 16:48:16.370115: I tensorflow/compiler/xla/service/service.cc:158]   StreamExecutor device (0): <undefined>, <undefined>
...

2019-04-06 16:48:16.635396: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1433] Found device 0 with properties: 
name: GeForce GTX 1060 3GB major: 6 minor: 1 memoryClockRate(GHz): 1.7085
pciBusID: 0000:02:00.0
totalMemory: 2.95GiB freeMemory: 2.77GiB
...
2019-04-06 16:48:16.635434: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1512] Adding visible gpu devices: 0
2019-04-06 16:48:16.637520: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1115] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 2541 MB memory) -> physical GPU (device: 0, name: GeForce GTX 1060 3GB, pci bus id: 0000:02:00.0, compute capability: 6.1)

Cela signifie que mon GPU est bien reconnu et utilisable par TensorFlow, c’est donc gagné !

Pour la suite

Lorsque TensorFlow sera enfin à jour pour CUDA 10.1, vous pourrez supprimer le paquet cuda-10-0 et le fichier /etc/yum.repos.d/cuda-f27.repo, puis remettre d’aplomb la base de packages: sudo dnf makecache.

TensorFlow est effectivmement un peu trop sensible à mon goût en ce qui concerne la version de CUDA. Cela étant dit, quand on connait un peu Fedora et la gestion de dépôts et de paquets, arriver à fire cohabiter deux versions de CUDA reste possible. Je dois bien l’admettre, c’est un peu trivial, mais je pense avoir donné les infos suffisantes ici pour arriver à travailler sans trop de souci.

En ce qui concerne CuDNN, vous pouvez vous en passer, l’utilisation de conda permet de soulager un peu le travail. Voici un exemple d’environnement conda qui vous permttra de faire du tensorflow sans trop de mal:

# installez conda depuis les paquets
sudo dnf install conda

# créez un environnement nommé tf avec tensorflow-gpu
conda new --name tf tensorflow-gpu

# activez l'environnement
conda activate tf

L’intérêt ici est que conda fourni la librairie cuDNN et semble ne pas avoir de souci de gestion de versions. Cela évite donc l’installation d’une série de RPM qui restent dans le système et de séparer par conséquent ces librairies dans un environnement spécifique. Personnellement je suis un gros consommateur de solutions de séparation d’environnement (cf. VirtualEnv, conda, Docker…) - j’évite le plus souvent possible d’avoir à modifier des fichiers dans les répertoire système.

À noter que, oui, je suis au courant de l’existence de “nvidia-docker” mais que je suis en train de tenter de passer de docker 1.13 (des dépôts Fedora) qui (selon ce qu’on me dit) n’est plus vraiment supporté, contre “moby-engine” qui est la version Docker “communautaire sans marque”. Je n’ai pas encore eut le temps de me pencher sur le sujet, mais ça va vite arriver.

Dans un prochain article, je vous montrerai comment créer un environnement “jupyter” capable de “voir” les autres environnements conda et par conséquent d’éviter la redondance d’installation de jupyeter pour les environnements séparés.

Mais pour l’heure, nous avons au moins installé les pilotes, conda en deux versions, et le tout sans tout casser dans notre système.

comments powered by Disqus