Journal Linux & Nvidia

Posté par bubar🦥 (Mastodon) le 22 novembre 2020 à 18:24. Licence CC By‑SA.

Étiquettes :

nov.

2020

Bonjour Nal< ?

Que se passe-t-il entre notre cher noyau Linux et Nvidia ? Nvidia, habituellement si prompt à supporter les dernières versions du noyau, a posté le 16 octobre :

«Due to an incompatibility issue, we advise customers to defer updating to Linux Kernel 5.9+ until mid-November when an NVIDIA Linux GPU driver update with Kernel 5.9+ support is expected to be available.»
_à cause d'une incompatibilité nous avertissons nos clients qu'il faut différer leur mise à jour vers le noyau 5.9 jusqu'à mi-novembre lorsqu'une mise à jour de notre driver devrait être disponible

L'annonce complète

"Habituellement si prompt à supporter Linux" ? Oui, sans conteste. Il y a également le fait que lorsqu'une nouvelle version du driver sort, elle fait tout fonctionner de suite. Alors que parfois, chez AMD comme chez Intel il fallait (au passé ?) attendre plusieurs versions pour avoir tantôt une sortie hdmi ok, tantôt un support pour telle ou telle extension d'opengl.
Deux avantages pour Nvidia.

Mais dans l'autre main il y a la problématique de leur blob, privateur, fermé, ayant une accès particulièrement privilégié au système s'il en a envie, ce n'est pas un simple logiciel. Et ce ne sont pas les timides avancées de Nvidia vers l'OpenSource (je n'ose dire Libre) qui changent ce fait.
Le support par Nouveau est de très bonne facture et permet d'utiliser des cartes Nvidia, discrètes ou pas, dans de confortables conditions de travail.
AMD fait un incroyable travail avec ses supports OpenSource et intégrés dans le noyau, leurs cartes récentes sont tout simplement fantastiques, et cela va au-delà de l'usage 'confortable' de bureau puisqu'il est possible d'avoir la pleine puissance pour ses usages. Parfait. AMD est le meilleur choix, et en rachetant Xillinx ils viennent de poser leur première pierre pour une développement probable autour de ~~la stupidité~~ l'intelligence artificielle, rattrapant bientôt son concurrent sur de probables cœurs Tensor.
Intel n'est pas en reste, avec une participation historiquement remarquable au noyau mais aussi à de nombreux niveaux du système gnu/linux, fait maintenant débarquer ses Xe, espérons seulement que le support de ses nouveaux gpu sera moins erratique que sur l’i915, où certains se voient ~~notabugafeature~~ boguer après quelques années.

Le kernel évolue, et si Linux met au coeur de son développement le fait «de ne pas casser l’userland» il n'hésite pas à faire évoluer ses arcanes internes. Si tu veux jouer dans le noyau, alors tu dois suivre le rythme.
Bien sûr certains arguent en faveur d'une interface stable pour les drivers. Permettant ainsi de plus facilement maintenir les-dits drivers. Maintenir ? Hum, .. maintenir à l'extérieur du noyau, donc user et abuser de la tolérance sur l'interprétation de la gplv2. Tolérance oui, n'importe quoi non (n'en déplaisent aux constructeurs de smartphones Android, autre exemple.)

Nvidia suit, lui, ok. Sauf de temps en temps. Et ça fait du bien (même si, possédant un 'vieux pc d'avant les supers gpu amd", ça m'a ennuyé un peu : peu importe) : ça fait du bien car cela nous rappelle, à nous utilisateurs (personnels ou professionnels) que la situation est anormale. Qu'AMD est un excellent compétiteur aujourd’hui, de plus intègre et intégré.

Ok, alors que s'est-il passé entre Nvidia et Linux, cette fois ?
Sur Nvidia et le 5.9, cela commence peut être bien par ici :
https://lore.kernel.org/netdev/20200728172703.GA5667@infradead.org/ (puis un patch en aout dernier) Trad incomplète, juste la fin et avec l'esprit :

une grande partie de sa daube semble juste être là pour contourner le GPL_EXPORT_SYMBOL, je suis vraiment d'accord avec Gred, cela ressemble beaucoup à une infâme tentative de troll

Côté AMD tout va bien :-) : allons relire un bel historique !
https://linuxfr.org/users/mathrack/liens/fusion-amd-xilinx
https://linuxfr.org/news/amd-continue-louverture-des-specifications-de-gpu
https://linuxfr.org/users/claudex/journaux/amd-et-plus-d-open-source
https://linuxfr.org/news/amd-s-investit-dans-ses-pilotes-libres

# Coté AMD tout n'est pas parfais non plus

Posté par xoddark le 22 novembre 2020 à 19:57. Évalué à 10.

Je suis plutôt un fervent défenseur des GPU AMD, mais tout n'est pas parfait non plus.

Exemple 1 : le support d'OpenCL avec le développement de Clover a été arrêté en faveur de ROCm. Si ROCm a des avantages, ce n'est pas disponible out-of-the-box, ça ne s'intègre pas forcément bien dans les distributions linux, et ça ne supporte que les GPU et carte mère avec des features récente mais pas forcément les dernier GPU.
Exemple 2 : les développements de code open source ne sont pas toujours fait en concertation avec la communauté (de développeur graphique linux) Cf: le post de blog de David Airlie : Linux graphics, why sharing code with Windows isn't always a win.

Par contre il quand même plein de bonne raison pour choisir plutôt des GPU AMD que Nvidia pour une utilisation sous linux.
J'ai suivi la progression des drivers opensource pour carte graphique AMD depuis presque le début, et il y a clairement beaucoup de travail et de progrès qui ont été fait.
Il est clair qu'une des limites pour faire mieux est clairement un manque de moyen.
Mais grâce à l'ouverture adopté par AMD :
- Des employé de Google et RedHat on pu développer un driver Vulkan intégré a Mesa pendant le le driver officiel d'AMD peinait à être disponible, et semble pas très adapté pour bien s'intégrer dans les distributions linux.
- Valve peut financer le développement d'un nouveau compilateur de Shader plus performant. Il s'appelle ACO, et est utilisé par défaut dans RADV(Vulkan) dans Mesa 20.2, et pourrait prochainement être utilisé par défaut également pour OpenGL

Donc merci à AMD, et à ceux qui améliore l'usage des GPU AMD sous linux, continuez comme ça.
- [^] # Re: Coté AMD tout n'est pas parfais non plus
  
  Posté par AlexTérieur le 24 novembre 2020 à 08:18. Évalué à 2.
  
  Exemple 1 : le support d'OpenCL avec le développement de Clover a été arrêté en faveur de ROCm. Si ROCm a des avantages, ce n'est pas disponible out-of-the-box, ça ne s'intègre pas forcément bien dans les distributions linux, et ça ne supporte que les GPU et carte mère avec des features récente mais pas forcément les dernier GPU.
  
  J'avais posté un journal où j'expliquais les difficultés d'avoir l'accélération OpenCL sur Fedora, en plus on a Clover et ROCm ne marchait pas ; on dirait que ça a changé depuis que je suis passé à Fedora 33, j'ai réussi à installer ROCm et à l'exploiter (testé sous Darktable).
  
  Pour plus d'info notamment sur l'installation et sur le matériel compatible, suivre ce lien.
# et nouveau ?

Posté par Eh_Dis_Mwan le 23 novembre 2020 à 10:29. Évalué à 1.

j'ai switché depuis quelques temps sur AMD, mais , je suis surpris que la driver nouveau ne fasse pas l'unanimité, j'avais cru comprendre que nouveau égalait nvidia en accélératon 2D/3D , c'est pas correct ?
- [^] # Re: et nouveau ?
  
  Posté par claudex le 23 novembre 2020 à 10:37. Évalué à 5.
  
  Non, pas du du tout, notamment la partie "Power Management" https://nouveau.freedesktop.org/FeatureMatrix.html qui permet de faire tourner la carte plus vite (par défaut, elle boot avec la fréquence la plus basse). Les dernières cartes ne permettent pas facilement à nouveau de les utiliser.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: et nouveau ?
    
    Posté par xoddark le 23 novembre 2020 à 12:57. Évalué à 2.
    
    En plus, de ce que j'ai suivie (je m'intéresse moins a nouveau/Nvidia), le support des GPU Nvidia avec Nouveau d'il y a 5/6 ans est pas mal, mais pour les CPU récent, c'est beaucoup moins bon.
    
    Par contre, des développeurs se sont intéressé au support de Clover pour Nouveau, et ça pourrais être intéressant pour améliorer le support d'OpenCL out-of-the-box sous Linux pour tout le monde 👍.
    
    Sources d'infos :
    - https://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.3-OpenCL-1.2-Clover
    - https://www.phoronix.com/scan.php?page=news_item&px=OpenCL-3.0-Prep-In-Clover
    - [^] # Re: et nouveau ?
      
      Posté par Thomas Debesse (site web personnel) le 24 novembre 2020 à 17:17. Évalué à 5.
      
      Je ne comprend pas vraiment pourquoi plus d’effort est investi dans Clover pour Nvidia que dans Clover pour AMD.
      
      La prise en charge de l’OpenCL pour AMD est désastreux car énormément fragmenté:
      https://gitlab.com/illwieckz/i-love-compute#frameworks
      
      Le pilote Clover pour AMD prend en charge toutes les cartes depuis la génération TeraScale 2 (~2010), il peut même se révéler très performant et battre le pilote propriétaire comme avec le raytracer LuxRender où le pilote Clover fait le double des performances Sauf qu’il est incomplet et en particulier il manque la prise en charge des images, ce qui le rend inutilisable pour des applications comme Darktable (développement photo). Et pour des raisons étonnantes, la prise en charge des images est actuellement activement développée… pour les cartes graphiques Nvidia qui sont bridées en performance quel que soit le niveau de qualité du pilote libre… Et au final, en dehors d’Intel les cartes les mieux supportées en terme de fonctionnalité (malgré les mauvaises performances) en libre seront les cartes Nvidia, de ce fabriquant qui ne respectent pas ses utilisateurs.
      
      ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: et nouveau ?
  
  Posté par Thomas Debesse (site web personnel) le 24 novembre 2020 à 17:08. Évalué à 4. Dernière modification le 24 novembre 2020 à 17:08.
  
  j'avais cru comprendre que nouveau égalait nvidia en accélératon 2D/3D , c'est pas correct ?
  
  Non pas du tout. J’ai fait quelques tests:
  https://wiki.unvanquished.net/wiki/GPU_compatibility_matrix
  
  En gros, avec une carte graphique capable de faire du 4K (3840×2160) avec tous les effets dans Unvanquished à 60fps, tu peux pas faire plus que du FullHD (1920×1080) pour conserver tes 60fps, et généralement to dois en plus désactiver des effets gourmands (relief mapping, etc.).
  
  Par ailleurs, quand les développeurs du noyau Linux ont désactivé l’AGP par défaut cet été, certains ordinateurs ont perdu toute capacité à piloter un écran correctement (parce qu’en réalité, l’alternative “PCI par AGP” est cassée depuis de nombreuses années), j’ai comparé plus en détail pour savoir où se situait le matériel rendu inutilisable. Et bien si tu souhaites utiliser le pilote nouveau, pour battre ce qui est probablement la meilleure carte AGP de ATI sortie en 2008 (Radeon HD 4670), tu dois prendre une Nvidia GTX 1060 sortie en 2016:
  https://lkml.org/lkml/2020/11/9/363
  
  Bien sûr cette même carte Nvidia sort du 4K à l’aise avec tous les effets activés et ne se compare plus à des cartes largement obsolètes quand utilisé avec le pilote propriétaire.
  
  Là où le pilote nouveau commence à rivaliser avec Nvidia c’est en terme de fonctionnalité implémentées, les développeurs de nouveau font un super nouveau et il ne manque que deux extensions pour que la prise en charge d’OpenGL 4.6 soit complète:
  https://mesamatrix.net/
  
  Mais par contre niveau performance c’est la catastrophe. Par ailleurs Nvidia signe les firmwares de manière à contraindre leurs clients à utiliser leur pilote propriétaire.
  
  Je ne comprend pas pourquoi la quasi totalité des machines vendues par des fabricants de PC prenant en charge Linux officiellement (en ordinateur portable, ça doit friser le 99%) intègrent du Nvidia…
  
  ce commentaire est sous licence cc by 4 et précédentes
# détails de l'histoire ?

Posté par Thomas Monjalon le 23 novembre 2020 à 10:37. Évalué à 4.

Ça a l'air d'être un échec intéressant.
Si je comprends bien, un développeur de Facebook propose un truc tarabiscoté (netgpu) dans le kernel pour faire du traitement de paquets dans le GPU. Son expérimentation ne fonctionne pour l'instant qu'avec Mellanox/Nvidia. Plusieurs mainteneurs dont celui de Mellanox/Nvidia lui répondent que c'est pourri :
https://lore.kernel.org/netdev/20200728233806.GC16789@nvidia.com/

Ensuite, ça déclenche un désir de bloquer ce genre de module :
http://lkml.iu.edu/hypermail/linux/kernel/2008.1/05371.html
"inherit TAINT_PROPRIETARY_MODULE"

Mais est-ce vraiment le problème actuellement rencontré pour le driver Nvidia en 5.9 ?
- [^] # Re: détails de l'histoire ?
  
  Posté par benoar le 01 décembre 2020 à 19:22. Évalué à 4.
  
  De ce que je comprends de l'histoire, on a Jonathan Lemon, un BSDiste ancien pas inconnu (auteur de kqueue), qui bosse aujourd'hui pour Facebook et qui envoie un patch de son adresse perso pour lier spécifiquement des GPU Nvidia à des cartes Ethernet Mellanox en utilisant l'infra du kernel. L'exemple d'utilisation est du Machine Learning sur GPU où les données transitent directement par la carte réseau à 200 Gbps (!) car sinon le bridge PCI-Express qui échangerait avec le CPU sature dans ce cas-là… Son truc est spécifique à son montage, et n'utilise pas l'infra de DMA inter-périphérique (p2p_dma) qui se trouve être une interface indiquée comme propageant là GPL pour tout code qui s'y lie ; coïncidence ou hasard… Il se trouve qu'en plus il dit ne pas avoir exporté les symboles de sa nouvelle API en _GPL car « c'était trop long à taper », ce qui pour une personne de sa trempe et vu le contexte (développement spécifique à Facebook, Nvidia toujours à vouloir niquer la GPL) s'est vu qualifier de trollage par Christoph Hellwig, développeur vétérant du kernel bien connu pour sa défense du Libre et de la GPL.
  
  Le patch proposé par Hellwig que tu montres après est très intéressant, car effectivement il semble avoir été écrit pile pour contrer ce genre de code, et les datent concordent (fin juillet dernier, ce dernier patch arrivant juste après l'incident ci-dessus) : les modules type « shim » qui sont là uniquement pour faire une interface sans valeur dans le but uniquement de lier un module à licence propriétaire — chose normalement proscrite par la GPL, mais que Nvidia utilise depuis plus de 10 ans, malgré les critiques de Torvalds et d'autres — deviennent rejetés. La discussion est ici :
  https://lore.kernel.org/lkml/20200730061027.29472-1-hch@lst.de/
  
  Mais est-ce vraiment le problème actuellement rencontré pour le driver Nvidia en 5.9 ?
  
  Ça semble vraiment être ça selon moi, et pourtant Nvivia a apparemment sorti un nouveau driver « compatible » avec le 5.9 :
  https://forums.developer.nvidia.com/t/download-nvidia-driver-r455-for-linux-kernel-5-9/159776
  
  En tous cas, remarque sarcastique de Greg KH sur le patch de Hellwig :
  
  Ah, the proven-to-be-illegal "GPL Condom" defense :)
  - [^] # Re: détails de l'histoire ?
    
    Posté par benoar le 03 décembre 2020 à 23:21. Évalué à 3.
    Nvivia a apparemment sorti un nouveau driver « compatible » avec le 5.9
    
    Je suis allé creuser : dans le driver qui vient de sortir en novembre on a un nouveau flag créé dans le Kbuild qui s'appelle « NV_BUILD_MAY_USE_GPL_SYMBOLS » (on peut donc forcer à violer la GPL, qu'ils indique comme « permission d'utiliser », même si par défaut il est à 0) :
```
diff -ru 455-455.32/usr/src/nvidia-455/nvidia-uvm/nvidia-uvm.Kbuild 455-455.45/usr/src/nvidia-455/nvidia-uvm/nvidia-uvm.Kbuild
--- 455-455.32/usr/src/nvidia-455/nvidia-uvm/nvidia-uvm.Kbuild  2020-10-15 00:58:52.000000000 +0200
+++ 455-455.45/usr/src/nvidia-455/nvidia-uvm/nvidia-uvm.Kbuild  2020-11-06 00:15:34.000000000 +0100
@@ -54,6 +54,13 @@
 NVIDIA_UVM_CFLAGS += -D__linux__
 NVIDIA_UVM_CFLAGS += -I$(src)/nvidia-uvm

+# Avoid using GPL symbols unless explicitly permitted to do so.
+NV_BUILD_MAY_USE_GPL_SYMBOLS ?= 0
+
+ifeq ($(NV_BUILD_MAY_USE_GPL_SYMBOLS),1)
+  NVIDIA_UVM_CFLAGS += -DNV_BUILD_MAY_USE_GPL_SYMBOLS
+endif
+
 # Avoid even building HMM until the HMM patch is in the upstream kernel.
 # Bug 1772628 has details.
 NV_BUILD_SUPPORTS_HMM ?= 0
```
    Ce flag est pour l'instant uniquement utilisé lors du test de la présence de l'API gérant l'affinité des threads par CPU (flag UVM_THREAD_AFFINITY_SUPPORTED) qui est maintenant à zéro même si l'API (en particulier celle indiquée par le flag NV_KTHREAD_CREATE_ON_NODE_PRESENT) est présente quand le driver n'est pas autorisé à violer la GPL : c'est la fonction kthread_create_on_node() ajoutée en 2011 par Éric Dumazet dans le commit 207205a2ba26 qui est GPL et est utilisée par le shim « libre » de Nvidia.
    
    Donc en fait je suppose qu'ainsi, les performances sont un peu dégradées car les threads ne sont pas créés sur le CPU le plus approprié pour la tâche, mais ça évite d'utiliser des symboles GPL dans ce shim, et donc de se faire bloquer comme violant la GPL par la nouvelle protection apportée par Hellwig. Je pensais que leurs dépendances étaient plus larges, si c'est le seul bout, on pourrait dire que c'est « bien joué » de la part de Nvidia, même si on sent quand même qu'ils aiment toujours bien jouer avec le feu.
    - [^] # Re: détails de l'histoire ?
      
      Posté par benoar le 03 décembre 2020 à 23:25. Évalué à 3.
      
      Pour ceux qui veulent aller voir le driver en question (dispo sur Ubuntu uniquement pour l'instant à priori) :
      https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/nvidia-kernel-source-455_455.45.01-0ubuntu1_amd64.deb
      - [^] # Re: détails de l'histoire ?
        
        Posté par Thomas Monjalon le 07 décembre 2020 à 22:21. Évalué à 1.
        
        Merci pour l'analyse.
        
        En espérant que cet énième incident incitera "tout le monde" à rentrer dans le droit chemin à plus ou moins court terme.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.