J'ai trouvé une demi-douzaine de publications à ce sujet sur le Web, mais aucune ne répond vraiment à la question.
Je souhaite configurer mon GPU nvidia pour ne faire que des calculs, pas pour piloter l'affichage. Mais lorsque je passe à l’utilisation du processeur graphique Intel dans la configuration nvidia-prime, je ne peux plus charger le module nvidia.
modprobe: ERROR: could not insert 'nvidia_352': No such device
Sans le module, CUDA ne fonctionne évidemment pas.
Alors, que fait exactement nvidia-prime pour empêcher le chargement du module? Ce n'est pas sur la liste noire. Il n'y a pas de fichier xorg.conf, alors comment le système sait-il utiliser le GPU Intel à la place du GPU discret?
Je suis sur un Dell 5510 Precision avec Ubuntu 14.04 installé en usine et mon GPU est Quadro M1000M.
Certains suggèrent d'utiliser bourdon, mais cela ne devrait pas être nécessaire pour des charges de calcul pures.
Apparemment, bumblebee est capable de charger le module. Alors, que fait-il exactement?
Mise à jour: Alors pourquoi semble-t-il toujours que je trouve la réponse lorsque je pose finalement une question, après des heures à essayer de la comprendre? Ce n’est qu’une réponse partielle, mais je suis sur quelque chose.
Jusqu'ici, j'ai déterminé que Prime fait au moins deux choses:
En utilisant bbswitch pour réactiver le GPU, je peux maintenant charger le module NVIDIA.
Mais la question demeure: quel est le meilleur moyen de configurer le système pour utiliser la carte NVIDIA uniquement pour les calculs?
Devrais-je configurer nvidia-prime pour utiliser le processeur graphique Intel et essayer de résoudre manuellement ce qui a permis de faire fonctionner CUDA?
Comment puis-je m'assurer que le système utilise toujours le processeur graphique Intel pour l'affichage?
Comment pourrais-je simplement désactiver NVIDIA prime et tout configurer manuellement?
Ou devrais-je juste céder et utiliser Bumblebee et optirun? Quels sont les inconvénients de ceci le cas échéant?
Des recommandations?
Je pense avoir au moins trouvé une solution superficielle à ce problème, comme décrit dans la mise à jour de mon message d'origine. Vraiment, j'ai trouvé deux solutions, même si je suis sûr qu'il y en a d'autres.
1 - Lorsque Prime est en mode Intel, réactivez la carte NVIDIA via bbswitch , puis exécutez modprobe nvidia
pour charger le module et créer les nœuds de périphérique.
2 - Utilisez l’optirun de Bumblebee pour lancer une session bash à partir de laquelle vous pourrez faire tout votre travail CUDA.
Ces deux solutions vous permettent d'utiliser les graphiques intégrés pour votre affichage, tout en utilisant la carte NVIDIA pour les charges de calcul. La solution optirun semble plus polyvalente, mais je préfère la première pour son minimalisme.
J'espère que quelqu'un avec plus de compréhension améliorera cette réponse.
Dans mon cas, j’ai constaté que la carte NVidia n’était pas désactivée et que la seule chose à faire pour exécuter le code CUDA était la suivante:
export LD_LIBRARY_PATH=/usr/lib/nvidia-352
dans le shell où je veux l'exécuter (je suppose que changer globalement le paramètre alternatif briserait la composition, etc., etc.)
Pour en arriver à ce point (sur un Dell Optiplex 7010, avec Ubuntu 14.04, CUDA 7.5 et une GTX 980), je crois que les étapes étaient les suivantes:
Tout semble bien fonctionner jusqu'à présent (nvidia-smi voit la carte, des échantillons de cuda sont envoyés, theano utilise la carte, etc.).
J'utilise la carte NVIDIA uniquement pour les exécutions CUDA et découvre cette approche:
J'utilise tout le temps la carte intel et cela est confirmé par la commande lspci | grep -E "VGA|3D"
:
00:02.0 VGA compatible controller: Intel Corporation Skylake Integrated Graphics (rev 06)
01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev ff)
Dans la ligne correspondante pour la carte NVIDIA, vous devriez voir (rev ff)
signifie que celle-ci est désactivée.
Pour allumer la carte et l'utiliser pour les calculs CUDA, j'utilise deux commandes suivantes:
Sudo prime-select nvidia
Sudo prime-switch
Après cette commande, lspci | grep -E "VGA|3D"
report:
00:02.0 VGA compatible controller: Intel Corporation Skylake Integrated Graphics (rev 06)
01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev a2)
Avis sur (rev a2)
, pas (rev ff)
dans la ligne correspondante. Maintenant, la carte est prête pour le calcul.
Après les calculs, j'utilise des actions en arrière:
Sudo prime-select intel
Sudo prime-switch
Et lspci | grep -E "VGA|3D"
rapporte:
00:02.0 VGA compatible controller: Intel Corporation Skylake Integrated Graphics (rev 06)
01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev ff)
Si quelqu'un trouve toujours des problèmes après avoir suivi les étapes de la réponse acceptée, essayez ceci:
echo "install bbswitch /bin/true" > /etc/modprobe.d/blacklist-bbswitch.conf
update-initramfs -u
Cela désactivera complètement bbswitch. L'inconvénient est que vous ne pourrez pas désactiver la carte NVIDIA pour économiser de l'énergie (Xorg utilise toujours les graphiques intégrés, à condition que prime-select intel
).
J'utilise un 1070 ti avec un thinkpad T420 dans un egpu mis en place pour exploiter la crypto-devise pendant que je travaille. Le GPU sera théoriquement rentabilisé après quelques mois de cette façon.
J'ai constaté qu'avec l'exportation nvidia 387, LD_LIBRARY_PATH =/usr/lib/nvidia-387 fonctionnait avec ethminer à l'aide de cuda.
Cependant, le seul moyen de faire fonctionner le système après un "premier choix d’informations" était si un deuxième moniteur était branché sur la carte lorsque je faisais la sélection et que je me déconnectais. Sinon, j'obtiendrais un message d'erreur "Le système fonctionne en mode graphique faible" ou un écran toujours vide. Bien sûr, lorsque je me connecte avec Intel Graphics, le moniteur branché sur le GPU n'affiche rien. Je dois donc le débrancher du gpu, puis le rebrancher sur le système (sortie dock DVI) pour exécuter la configuration de mon moniteur en duel. .
Je pense que c’est parce que gpu-manager détecte que bbswitch ne fonctionne pas, puis supprime la configuration xorg.
Je poste ceci pour montrer une solution de contournement pour les quelques personnes qui pourraient se trouver dans une situation similaire, mais aussi pour voir si quelqu'un a une idée pour empêcher cela de se produire, car le fait de devoir déplacer ce câble à chaque redémarrage est un peu un problème. inconvénient.
fichier_journal: /var/log/gpu-manager.log
last_boot_file:/var/lib/ubuntu-drivers-common/last_gfx_boot nouveau_boot_file:/var/lib/ubuntu-drivers-common/last_gfx_boot ne peut pas accéder/exécuter/udc-fglrx-chargé Le fichier chargé ne contient pas de fichier. /modules/4.4.0-104-generic/updates/dkms Recherche de modules nvidia dans /lib/modules/4.4.0-104-generic/updates/dkms Module nvidia trouvé: nvidia_387_drm.ko Nvidia est-il chargé? oui nvidia at-il été déchargé? non Nvidia est-il sur la liste noire? oui fglrx est-il chargé? non fglrx a-t-il été déchargé? non fglrx est-il sur la liste noire? non intel est-il chargé? oui Radeon est-il chargé? non radeon est-il sur la liste noire? non amdgpu est-il chargé? non amdgpu est-il sur la liste noire? non Nouveau est chargé? non Nouveau est-il sur la liste noire? oui Le module de noyau fglrx est-il disponible? non Le module de noyau nvidia est-il disponible? oui Vendor/Numéro de périphérique: 8086: 126 BusID "PCI: 0 @ 0: 2: 0" Est-ce que boot vga? oui Vendor/Device Id: 10de: 1b82 BusID "PCI: 5 @ 0: 0: 0" Est-ce que boot vga? non Sauter "/ dev/dri/card1", piloté par "i915" Sauter "/ dev/dri/card0", piloté par "nvidia-drm" Sauter "/ dev/dri/card1", piloté par "i915" Sauter "/dev/dri/card0 ", piloté par" nvidia-drm "Saut"/dev/dri/card1 ", piloté par" i915 "Saut" "/ dev/dri/card0", piloté par "nvidia-drm" trouvé "/ dev/dri/card1 ", piloté par" i915 "sortie 0: card1-LVDS-1 sortie 1: card1-HDMI-A-2 Nombre de sorties connectées pour/dev/dri/card1: 2 Doit-il être déchargé? oui dernier numéro de cartes = 2 A amd? non intel? oui a nvidia? oui combien de cartes? 2 Le système a-t-il changé? Non main_Arch_path x86_64-linux-gnu, other_Arch_path i386-linux-gnu Alternative actuelle: /usr/lib/nvidia-387-prime/ld.so.conf Alternative principale: (null) Alternative egl actuelle:/usr/lib/nvidia -387-prime/ld.so.conf nvidia est-il activé? Non Est-ce que nvidia egl est activé? non fglrx est-il activé? non Mesa est-il activé? non Mesa egl est-il activé? non pxpress est-il activé? non Est-ce que Prime est activé? oui Prime egl est-il activé? oui nvidia est-il disponible? oui Est-ce que nvidia egl est disponible? non fglrx est-il disponible? non fglrx-core est-il disponible? non Mesa est-il disponible? oui Mesa egl est-il disponible? oui Est-ce que pxpress est disponible? non Prime est-il disponible? oui Prime egl est-il disponible? aucune version du pilote Nvidia du système hybride Intel détectée/sys/classe/dmi/id/version_produit = "ThinkPad T420"/sys/classe/dmi/id/nom_produit = "4236L23" 1er essai: bbswitch sans quirks Chargement de bbswitch avec Paramètres "load_state = -1 unload_state = 1" Erreur: impossible d'ouvrir/proc/acpi/bbswitch Suppression de xorg.conf. Chemin: /etc/X11/xorg.conf ne peut pas accéder à /usr/share/gpu-manager.d/hybrid-power-saving Pas besoin de changer le statut actuel de bbswitch
Si je nano xorg.conf après cela, il est vide. Je poste ceci après avoir fait le tour du moniteur, avec l'extraction en arrière-plan, et mon xorg.conf est toujours vide. Donc, je suppose que pour une raison quelconque, lorsque je garde le moniteur branché sur le GPU lors du redémarrage de lightdm, le fait que mon xorg.conf soit supprimé n'a pas d'importance. Des idées?