Pilote GPU Nvidia 4090 piraté, activation du P2P

 (github.com/tinygrad)
1 points par GN⁺ 2024-04-13 | 1 commentaires | Partager sur WhatsApp
  • Ce dépôt est la publication du code source des modules noyau GPU open source NVIDIA pour Linux, et la version indiquée dans le README est 565.57.01
  • Les modules noyau compilés doivent être utilisés avec le firmware GSP et les composants du pilote GPU NVIDIA en espace utilisateur de la même version de pilote 565.57.01
  • Les plateformes prises en charge sont x86_64 et aarch64, et les noyaux Linux pris en charge couvrent la même plage que les modules noyau propriétaires NVIDIA, soit actuellement 4.15 et plus
  • Les modules noyau sont divisés entre des composants indépendants du système d’exploitation et une couche d’interface avec le noyau Linux, qui doit être compilée pour le noyau cible
  • Les GPU compatibles sont les GPU Turing et ultérieurs, et le tableau liste divers produits GeForce, RTX et séries A/H/L, dont la NVIDIA GeForce RTX 4090, avec leurs identifiants PCI

Versions et conditions de compilation

  • Ce dépôt est la publication du code source des NVIDIA Linux open GPU kernel modules et sa version est 565.57.01
  • La commande de compilation de base est la suivante
    • make modules -j$(nproc)
  • Avant l’installation, il faut supprimer les modules noyau NVIDIA existants, puis exécuter la commande suivante avec les privilèges root
    • make modules_install -j$(nproc)
  • Les modules noyau compilés ici nécessitent le firmware GSP et les composants du pilote GPU NVIDIA en espace utilisateur de la version de pilote 565.57.01 correspondante
    • L’exemple donné consiste à installer le fichier .run du pilote GPU NVIDIA avec l’option --no-kernel-modules

Architectures prises en charge et toolchain

  • Les modules noyau peuvent actuellement être compilés pour x86_64 ou aarch64
  • En compilation croisée, il faut préciser TARGET_ARCH=aarch64|x86_64 ainsi que CC, LD, AR, CXX, OBJCOPY sur la ligne de commande make
  • La compilation peut se faire avec une version relativement récente de GCC ou de Clang
  • La couche d’interface avec le noyau des modules noyau doit être compilée avec la toolchain utilisée pour compiler le noyau cible
  • Les versions de noyau Linux prises en charge sont les mêmes que pour les modules noyau propriétaires NVIDIA, soit actuellement Linux kernel 4.15 et plus

Options de compilation

  • NV_VERBOSE=1 affiche l’ensemble des commandes exécutées
    • Par défaut, seules de courtes lignes CC sont affichées
  • DEBUG=1 compile les modules noyau en build de débogage
    • La build par défaut est compilée sans informations de débogage
    • Cette option active aussi plusieurs messages de journalisation de débogage des modules noyau

Structure des modules noyau

  • La plupart des modules noyau NVIDIA sont divisés en deux composants
    • Composant OS-agnostic : partie indépendante du système d’exploitation
    • kernel interface layer : partie spécifique à la version et à la configuration du noyau Linux
  • Dans le paquet d’installation NVIDIA .run, les composants OS-agnostic sont fournis sous forme binaire
    • Ce composant est volumineux et long à compiler, donc une version précompilée est fournie afin d’éviter à l’utilisateur de le recompiler à chaque installation du pilote
    • Le nom de ce composant dans nvidia.ko est nv-kernel.o_binary
    • Le nom de ce composant dans nvidia-modeset.ko est nv-modeset-kernel.o_binary
    • nvidia-drm.ko et nvidia-uvm.ko ne contiennent pas de composant OS-agnostic
  • La couche d’interface avec le noyau de chaque module noyau doit être compilée pour le noyau cible

Organisation des répertoires et intégration avec Nouveau

  • Les principaux répertoires ont les rôles suivants
    • kernel-open/ : couche d’interface avec le noyau
    • kernel-open/nvidia/ : couche d’interface avec le noyau pour nvidia.ko
    • kernel-open/nvidia-drm/ : couche d’interface avec le noyau pour nvidia-drm.ko
    • kernel-open/nvidia-modeset/ : couche d’interface avec le noyau pour nvidia-modeset.ko
    • kernel-open/nvidia-uvm/ : couche d’interface avec le noyau pour nvidia-uvm.ko
    • src/ : code OS-agnostic
    • src/nvidia/ : code OS-agnostic pour nvidia.ko
    • src/nvidia-modeset/ : code OS-agnostic pour nvidia-modeset.ko
    • src/common/ : code utilitaire utilisé par nvidia.ko et/ou nvidia-modeset.ko
    • nouveau/ : outils d’intégration du pilote de périphérique Nouveau
  • Les scripts Python du répertoire nouveau extraient certaines images binaires de firmware encodées dans le code source, ainsi que des données associées, pour les enregistrer dans des fichiers séparés
  • Ces fichiers sont utilisés par le pilote de périphérique Nouveau pour charger et faire communiquer le firmware GSP
  • La disposition des fichiers binaires est décrite dans nouveau_firmware_layout.ods, un fichier au format OpenDocument Spreadsheet

Contributions et gestion des problèmes

  • Les contributions se font via la création de pull requests dans le dépôt open-gpu-kernel-modules de NVIDIA
  • Lors de la soumission d’une pull request, l’acceptation du Contributor License Agreement est requise
  • Cette base de code est partagée avec le pilote propriétaire NVIDIA, et les sources publiées sont générées à partir du code partagé après plusieurs traitements
    • Le dépôt GitHub fonctionne principalement comme un snapshot de chaque version de pilote
    • Il ne faut pas s’attendre à disposer d’un historique de révision des changements individuels effectués dans la base de code partagée de NVIDIA
    • Il est probable qu’il n’y ait qu’un seul commit git par version de pilote
    • Les contributions individuelles peuvent ne pas être intégrées sous forme de commits git séparés dans le dépôt GitHub
    • En raison du processus de traitement avant publication, l’application des contributions à la base de code partagée nécessite une fusion manuelle
    • Les gros refactorings peuvent être difficiles à fusionner et à accepter, ce qui demande un contact et une coordination en amont
  • Les problèmes liés aux Open GPU Kernel Modules peuvent être signalés via les Issues du dépôt NVIDIA, les forums développeurs NVIDIA ou linux-bugs@nvidia.com
  • En cas de découverte d’une faille de sécurité, il faut consulter le document séparé SECURITY.md

Périmètre des GPU compatibles

  • Les modules noyau open source de NVIDIA peuvent être utilisés sur les GPU Turing et ultérieurs
  • Pour le détail du support fonctionnel et des limitations, il est indiqué de consulter le document kernel_open.html du README utilisateur final du pilote GPU NVIDIA
  • Pour la prise en charge vGPU, il faut consulter README.vgpu inclus dans le vGPU Host Package
  • Le tableau des GPU compatibles liste le nom du produit et l’identifiant PCI
    • Lorsqu’il y a trois identifiants, le premier est le PCI Device ID, le deuxième le PCI Subsystem Vendor ID, et le troisième le PCI Subsystem Device ID
    • Le tableau comprend de nombreux produits, dont NVIDIA GeForce RTX 4090, NVIDIA GeForce RTX 4090 D, NVIDIA GeForce RTX 4080 SUPER, NVIDIA GeForce RTX 4070 Ti SUPER, NVIDIA H100, NVIDIA H200, NVIDIA GH200 et NVIDIA L40S

À lire aussi

1 commentaires

 
GN⁺ 2024-04-13
Commentaires sur Hacker News

  • Impressionnant. Je me demandais si c’était possible, et maintenant il ne reste plus qu’à trouver le temps de monter une machine 4x4090 pour des LLM locaux
    Avec la parallélisation tensorielle, ce sera probablement bien moins cher et plus rapide qu’un H100 SXM pour l’inférence. Je ne comprends toujours pas pourquoi tinybox a choisi une configuration à 6 GPU. Beaucoup de charges de travail tournent bien seulement avec 4 ou 8 GPU, donc là on a l’impression de payer pour 6 mais de n’en utiliser que 4, ou d’avoir une config bancale au lieu de 8

    • tinygrad prend en charge le partitionnement non uniforme. Il n’y a pas de raison fondamentale d’être à 4 ou 8 ; si le logiciel est bon, le travail peut être presque entièrement parallélisé quel que soit le nombre de GPU
      Ils ont choisi 6 parce qu’il y a 128 lignes PCIe, soit 8 ports x16. Si on en utilise 1 pour le NVMe et 1 pour le réseau, on peut relier 6 GPU en full fabric. Avec seulement 4, on gaspille du PCIe, et avec 8, il ne reste pratiquement plus de connectique externe à part quelques ports USB3
    • S’il y a 6 GPU, c’est parce qu’il faut du stockage rapide, et que ça consomme des lignes PCIe
      L’objectif était aussi de faire tourner un modèle 70B en FP16, ce qui demande environ 140 Go de VRAM. 6*24 Go = 144 Go, donc ça colle
    • 6 semble raisonnable. Sur les 128 lignes du ThreadRipper, une partie doit aller au réseau et au NVMe
      Par exemple, 4 NVMe nécessitent x16 lignes, et du réseau 10G demande encore x4 lignes
    • J’ai regardé la documentation récemment publiée sur le NVIDIA SXM2, et SXM2/NVLink 2.0 semblait aussi utiliser des systèmes à 6 voies
      NVIDIA SXM a ensuite été mis à jour en versions 3 et 4, et cette configuration n’est pas basée là-dessus, mais il y a peut-être d’autres raisons qui rendent le 6-way pertinent
    • Ce serait bien si tu pouvais partager les détails du build que tu envisages. J’ai besoin d’un serveur pour le labo, mais il y a tellement d’options que j’ai du mal à m’y retrouver

  • C’est vraiment une très bonne nouvelle. Dans le milieu universitaire, je connais plusieurs labos qui ont monté des machines avec plusieurs 4090 sans se rendre compte que Nvidia avait bloqué la communication P2P entre les cartes
    C’était aussi l’une des raisons pour lesquelles je n’avais pas acheté de 4090, même si c’était bien moins cher pour mon usage. Ce n’est pas du NVLink, mais comme Nvidia a quasiment supprimé NVLink sur tout ce qui n’est pas ultra haut de gamme, c’est toujours mieux que rien. Fin de l’an dernier, j’ai demandé un devis pour 4 H100 avec NVLink, et le délai était de 13 mois ; les produits sans NVLink pouvaient être livrés en 4 mois. Pour l’instant, j’ai acheté 4 L40S pour faire tenir le labo, mais les problèmes de chaîne d’approvisionnement et l’énorme flambée des prix rendent la recherche très difficile. C’est très loin de suffire pour soutenir 6 doctorants et plusieurs étudiants de licence
    Dans mon ancienne université, vers 2015-2018, on pouvait monter des machines à 2 GPU avec NVLink pour 5 000 dollars pièce et en mettre une sous le bureau de chaque étudiant ; c’était bien plus simple à l’époque

    • Même avant ça, Nvidia nous compliquait déjà la vie en supprimant progressivement les designs blower sur les cartes grand public qu’on pouvait mettre en serveur
      Du point de vue d’un labo, je choisirais volontiers une carte avec un MTBF divisé par deux si elle coûte 1/4 du prix
    • Par rapport aux fournisseurs de GPU cloud, ça donne quoi côté coût ?

  • Ici, P2P veut dire quoi ? En cherchant, j’ai l’impression que c’est peer to peer, mais dans le contexte des cartes graphiques, qu’est-ce que ça signifie ?

    • Ça veut dire que lorsqu’on envoie des données depuis la mémoire d’un GPU vers un autre GPU, elles n’ont pas besoin de passer par la RAM système. https://xilinx.github.io/XRT/master/html/p2p.html
    • Il s’agit d’un accès mémoire partagé entre GPU Nvidia
      https://developer.nvidia.com/gpudirect
    • Le terme exact, et celui qu’on employait le plus souvent avant, c’est bus mastering
    • C’est un terme idiot. À ce compte-là, on pourrait aussi appeler un lien RS-232 du peer to peer

  • J’aimerais que davantage de fabricants de matériel publient leur documentation et laissent la communauté découvrir le reste
    C’est similaire à ce qui s’est passé avec les premiers IBM VGA. Il suffit de regarder « Mode X », les vrais modes matériels au-delà du BIOS, ou même le 800x600x16. Malheureusement, la plupart semblent préférer contrôler étroitement tous les aspects de l’usage de leurs produits afin de soutirer davantage d’argent à leur base d’utilisateurs. À mon avis, la période où les PC étaient les plus productifs était aussi celle où ils étaient les plus ouverts

    • Dans ce cas, il devient impossible de faire payer des prix différents à des clients différents pour le même matériel. Ce n’est pas gagnant pour tout le monde
    • Si j’étais un fabricant de matériel et que le verrouillage logiciel des fonctions produit ne marchait pas, je passerais simplement à un verrouillage matériel
      Les produits coûteraient alors tout simplement plus cher
    • L’ouverture était certes formidable, mais elle n’était pas indispensable en soi. Les gens arrivent aussi à comprendre les systèmes fermés
      L’interopérabilité antagoniste (adversarial interoperability) était courante, et qu’ils le veuillent ou non, les fabricants voyaient leurs logiciels fonctionner grâce à la rétro-ingénierie. Ce qui était rare autrefois mais courant aujourd’hui, c’est le verrouillage logiciel et matériel. La cryptographie aurait dû être une technologie qui nous donne du pouvoir, mais elle a fini par servir à nous exclure de nos propres machines. Nous ne sommes plus aux commandes. Même le système d’exploitation ne contrôle plus vraiment le système. Même un système Linux libre n’est plus qu’un « OS utilisateur » à l’intérieur d’un assemblage de firmware propriétaire et de silicium dont le fabricant lui-même ne connaît pas toujours les détails, presque un petit composant mis en sandbox par rapport au fonctionnement réel
    • Le logiciel de Nvidia, c’est leur fossé défensif

  • Quand Nvidia a supprimé NVLink de sa gamme grand public, son argument initial était que le PCIe 5 serait suffisamment rapide
    Sauf que la série 40xx est sortie sans PCIe 5 ni support P2P. C’est déjà bien d’en récupérer au moins la moitié, mais j’ai du mal à imaginer que ce soit encore autorisé dans le firmware de la génération suivante

  • C’est l’une des fonctionnalités désactivées sur les cartes grand public pour assurer une segmentation du marché ?

    • Oui, dans une certaine mesure
      Avec une analogie imparfaite, imagine un petit lotissement d’environ 15 maisons en construction. Normalement, on place un transformateur de 200 kVA au coin de la rue pour fournir une puissance adaptée depuis le réseau. Mais faute de transformateurs, l’entreprise installe un modèle commercial de 1 250 kVA. Il peut alimenter bien plus de maisons que nécessaire et fonctionne donc avec une énorme marge. Un jour, un habitant veut lancer une grosse installation de culture et découvre comment activer à lui seul cette capacité excédentaire du transformateur. Ce que geohot a trouvé, c’est précisément cette « activation »
    • Je vais sans doute me faire massivement downvoter, mais j’aimerais que ce genre de pratique sur les appareils grand public soit interdit ou très lourdement taxé
    • Il n’y a absolument aucun intérêt à implémenter et tester cette fonctionnalité sur des GPU grand public. Les configurations multi-GPU pour le jeu n’ont presque jamais vraiment bien fonctionné

  • J’ai toujours admiré les talents de hacker de George Hotz. Ça a aussi beaucoup inspiré mes projets personnels

    • Suivre son processus de développement est vraiment fascinant. Sa générosité à le partager mérite aussi d’être soulignée
      Il bute souvent sur des problèmes superficiels et arbitraires qui sembleraient moins difficiles à des ingénieurs plus expérimentés. On le voit aussi régulièrement écrire du très mauvais code, voire du code carrément faux. L’épisode lié à Twitter en est un bon exemple. Et pourtant, à force de persévérance en solo et d’itérations constantes, il produit tout aussi souvent des améliorations étonnantes. C’est un très bon exemple dont on peut s’inspirer
    • Ses streams me stimulent énormément. La concentration et l’effort sont au cœur des bons résultats et, avec une vision claire et une stratégie, on peut aussi atteindre le succès
      Félicitations à geohot ainsi qu’à tous les contributeurs de tinygrad/comma
    • Il a la concentration d’un pilote militaire en long-courrier
    • Son laptop Xbox360 a été une source majeure de motivation pendant mon adolescence

  • En parcourant le README, pour ceux que ça intéresse : il s’agit de P2P sur PCIe, pas de NVLink

    • Les RTX 40 n’ont pas de NVLink sur le PCB, mais comme certaines cartes de la même famille le prennent en charge, il doit être présent dans le silicium. À mon avis, ça a probablement été désactivé par fusibles
    • Si je ne me trompe pas, la 4090 ne prend pas en charge PCIe 5.0, donc c’est limité à des vitesses PCIe 4.0. C’est quand même une amélioration

  • Dans les prochaines architectures, ils vont sûrement commencer à verrouiller ça dans le firmware, donc autant en profiter tant que ça dure

    • Oui, mais de toute façon ça devait arriver un jour ou l’autre
      Donc autant pouvoir en profiter au moins pendant une génération plutôt que pas du tout

  • Je me demande si c’est George lui-même qui l’a fait, ou quelqu’un attiré par la prime mise en place par tinycorp
    Et j’aimerais demander aux gens qui connaissent bien les couches basses de PCI : est-ce que ça ne ressemble pas plutôt à quelque chose que NVIDIA n’a simplement pas pris la peine d’empêcher, plutôt qu’à quelque chose qu’ils ont activement cherché à bloquer ?

    • Les périphériques PCI ont toujours pu lire et écrire dans un espace d’adressage partagé. Ils restent soumis aux contraintes de l’IOMMU, mais en général cela servait surtout au DMA vers la RAM système, sans s’y limiter pour autant
      Donc il semble logique de configurer les périphériques pour exposer l’intégralité de la VRAM dans l’espace d’adressage. Il suffit d’avoir le support du resizable BAR, ou bien un BAR de taille fixe suffisamment grand. Et il paraît tout aussi logique d’indiquer à une carte de lire et écrire à des adresses mappées vers la VRAM d’une autre carte. Je me demande si le goulot d’étranglement viendra de la capacité de commutation PCIe, ou des liens point à point et de la VRAM. Dans tous les cas, réduire les allers-retours via la RAM système devrait aider
    • Le commit est au nom de geohot, donc on dirait bien que c’est George lui-même
    • Les avancées ont aussi été consignées sur le Discord tinygrad