Journal Linux & Nvidia

Posté par  . Licence CC By‑SA.
Étiquettes :
15
22
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  . Évalué à 10 (+15/-0).

    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  . Évalué à 1 (+0/-0).

      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  . Évalué à 1 (+0/-0).

    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  . Évalué à 5 (+2/-0).

      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  . Évalué à 2 (+1/-0).

        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  (site Web personnel) . Évalué à 4 (+1/-0).

          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  (site Web personnel) . Évalué à 4 (+1/-0). Dernière modification le 24/11/20 à 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  . Évalué à 3 (+2/-0).

    Ç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 ?

Envoyer un commentaire

Suivre le flux des commentaires

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