Gehackter Nvidia-4090-GPU-Treiber aktiviert P2P

 (github.com/tinygrad)
1 Punkte von GN⁺ 2024-04-13 | 1 Kommentare | Auf WhatsApp teilen
  • Dieses Repository ist der Source-Release der NVIDIA Linux Open GPU Kernel Modules; laut README ist die Version 565.57.01
  • Die gebauten Kernel-Module müssen zusammen mit der GSP-Firmware und den User-Space-Komponenten des NVIDIA-GPU-Treibers derselben Treiber-Release 565.57.01 verwendet werden
  • Unterstützt werden x86_64 und aarch64; bei den Linux-Kernels wird derselbe Bereich wie beim proprietären NVIDIA-Kernel-Modul unterstützt, aktuell 4.15 oder neuer
  • Die Kernel-Module sind in OS-unabhängige Komponenten und die Linux-Kernel-Interface-Schicht aufgeteilt; die Kernel-Interface-Schicht muss passend zum Ziel-Kernel gebaut werden
  • Kompatible GPUs sind GPUs ab Turing; in der Tabelle sind mehrere GeForce-, RTX- sowie A/H/L-Serien-Produkte einschließlich der NVIDIA GeForce RTX 4090 mit PCI-IDs aufgeführt

Releases und Build-Bedingungen

  • Dieses Repository ist der Source-Release der NVIDIA Linux Open GPU Kernel Modules in Version 565.57.01
  • Der Standard-Build-Befehl lautet wie folgt
    • make modules -j$(nproc)
  • Vor der Installation müssen bestehende NVIDIA-Kernel-Module entfernt werden; anschließend wird mit Root-Rechten Folgendes ausgeführt
    • make modules_install -j$(nproc)
  • Die hier gebauten Kernel-Module benötigen die GSP-Firmware und die User-Space-Komponenten des NVIDIA-GPU-Treibers der entsprechenden Treiber-Release 565.57.01
    • Als Beispiel wird gezeigt, die NVIDIA-GPU-Treiber-.run-Datei mit der Option --no-kernel-modules zu installieren

Unterstützte Architekturen und Toolchain

  • Die Kernel-Module können derzeit für x86_64 oder aarch64 gebaut werden
  • Beim Cross-Compiling werden zusammen mit TARGET_ARCH=aarch64|x86_64 auch CC, LD, AR, CXX, OBJCOPY in der make-Kommandozeile angegeben
  • Es kann mit relativ aktuellen Versionen von GCC oder Clang gebaut werden
  • Die Kernel-Interface-Schicht der Kernel-Module muss mit derselben Toolchain gebaut werden, die auch zum Bauen des Ziel-Kernels verwendet wurde
  • Die unterstützten Linux-Kernel-Versionen entsprechen dem Bereich, den das proprietäre NVIDIA-Kernel-Modul unterstützt; aktuell Linux kernel 4.15 oder neuer

Build-Optionen

  • NV_VERBOSE=1 gibt die vollständigen ausgeführten Befehle aus
    • Standardmäßig werden nur kurze CC-Zeilen ausgegeben
  • DEBUG=1 kompiliert die Kernel-Module als Debug-Build
    • Der Standard-Build wird ohne Debug-Informationen kompiliert
    • Diese Option aktiviert außerdem verschiedene Debug-Log-Meldungen der Kernel-Module

Struktur der Kernel-Module

  • Der Großteil der NVIDIA-Kernel-Module ist in zwei Komponenten aufgeteilt
    • OS-agnostic-Komponente: vom Betriebssystem unabhängiger Teil
    • kernel interface layer: Teil, der auf Linux-Kernel-Version und -Konfiguration spezialisiert ist
  • Im NVIDIA-.run-Installationspaket wird die OS-agnostic-Komponente als Binärdatei bereitgestellt
    • Diese Komponente ist groß und benötigt lange zum Kompilieren; deshalb wird eine vorgebaute Version bereitgestellt, damit Nutzer sie nicht bei jeder Treiberinstallation erneut kompilieren müssen
    • Der entsprechende Komponentenname in nvidia.ko ist nv-kernel.o_binary
    • Der entsprechende Komponentenname in nvidia-modeset.ko ist nv-modeset-kernel.o_binary
    • nvidia-drm.ko und nvidia-uvm.ko haben keine OS-agnostic-Komponente
  • Die Kernel-Interface-Schicht jedes Kernel-Moduls muss passend zum Ziel-Kernel gebaut werden

Verzeichnisstruktur und Nouveau-Integration

  • Die wichtigsten Verzeichnisse haben folgende Aufgaben
    • kernel-open/: Kernel-Interface-Schicht
    • kernel-open/nvidia/: Kernel-Interface-Schicht für nvidia.ko
    • kernel-open/nvidia-drm/: Kernel-Interface-Schicht für nvidia-drm.ko
    • kernel-open/nvidia-modeset/: Kernel-Interface-Schicht für nvidia-modeset.ko
    • kernel-open/nvidia-uvm/: Kernel-Interface-Schicht für nvidia-uvm.ko
    • src/: OS-agnostic-Code
    • src/nvidia/: OS-agnostic-Code für nvidia.ko
    • src/nvidia-modeset/: OS-agnostic-Code für nvidia-modeset.ko
    • src/common/: Utility-Code, der von nvidia.ko und/oder nvidia-modeset.ko verwendet wird
    • nouveau/: Tools zur Integration mit dem Nouveau-Gerätetreiber
  • Die Python-Skripte im Verzeichnis nouveau extrahieren einige im Source-Code kodierte Firmware-Binärimages und zugehörige Daten und speichern sie als separate Dateien
  • Diese Dateien werden vom Nouveau-Gerätetreiber verwendet, um die GSP-Firmware zu laden und mit ihr zu kommunizieren
  • Das Layout der Binärdateien ist in nouveau_firmware_layout.ods beschrieben; diese Datei liegt im OpenDocument-Spreadsheet-Format vor

Beiträge und Bearbeitung von Issues

  • Beiträge erfolgen durch das Erstellen eines Pull Requests im NVIDIA-Repository open-gpu-kernel-modules
  • Beim Einreichen eines Pull Requests ist die Zustimmung zur Contributor License Agreement erforderlich
  • Diese Codebasis wird mit dem proprietären NVIDIA-Treiber geteilt; der veröffentlichte Source-Code entsteht durch mehrere Verarbeitungsschritte des gemeinsamen Codes
    • Das GitHub-Repository fungiert im Wesentlichen wie ein Snapshot jeder Treiber-Release
    • Eine Revision History einzelner Änderungen aus der gemeinsamen NVIDIA-Codebasis ist voraussichtlich nicht verfügbar
    • Pro Treiber-Release gibt es wahrscheinlich nur einen Git-Commit
    • Einzelne Beiträge werden im GitHub-Repository möglicherweise nicht als eigener Git-Commit übernommen
    • Wegen der Verarbeitung vor der Veröffentlichung ist zum Übernehmen von Beiträgen in die gemeinsame Codebasis ein manuelles Merging erforderlich
    • Größere Refactorings können schwer zusammenzuführen und zu übernehmen sein; daher sind vorherige Kontaktaufnahme und Abstimmung erforderlich
  • Probleme im Zusammenhang mit den Open GPU Kernel Modules können über die Issues des NVIDIA-Repositorys, die NVIDIA-Entwicklerforen oder an linux-bugs@nvidia.com gemeldet werden
  • Wenn eine Sicherheitslücke gefunden wird, soll das separate Dokument SECURITY.md konsultiert werden

Bereich kompatibler GPUs

  • Die NVIDIA Open Kernel Modules können auf GPUs ab Turing verwendet werden
  • Für Details zu Funktionsunterstützung und Einschränkungen wird auf kernel_open.html im NVIDIA GPU driver end user README verwiesen
  • Für vGPU-Unterstützung soll README.vgpu aus dem vGPU Host Package konsultiert werden
  • Die Tabelle kompatibler GPUs listet Produktnamen zusammen mit PCI-IDs auf
    • Wenn drei IDs vorhanden sind, ist die erste die PCI Device ID, die zweite die PCI Subsystem Vendor ID und die dritte die PCI Subsystem Device ID
    • In der Tabelle sind unter anderem 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 und NVIDIA L40S aufgeführt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-13
Meinungen auf Hacker News

  • Großartig. Ich hatte mich gefragt, ob das möglich ist; jetzt ist das Einzige, was einem 4x4090-System für lokale LLMs noch im Weg steht, die Zeit, es zu bauen.
    Wenn Tensor-Parallelisierung funktioniert, dürfte das bei der Inferenz viel günstiger und schneller sein als H100 SXM. Allerdings verstehe ich immer noch nicht, warum tinybox sich für eine Konfiguration mit 6 GPUs entschieden hat. Viele Workloads laufen nur mit 4 oder 8 wirklich gut; so wirkt es, als zahle man derzeit für 6 und nutzt nur 4, oder landet in einer unausgewogenen Konfiguration, die nicht 8 ist.

    • tinygrad unterstützt ungleiche Aufteilung. Es gibt keinen grundlegenden Grund, warum es 4 oder 8 sein müssen; mit guter Software lässt sich Arbeit bei jeder Anzahl von GPUs nahezu vollständig parallelisieren.
      Der Grund für 6 ist, dass es 128 PCIe-Lanes gibt, also acht x16-Ports. Wenn man einen für NVMe und einen für Netzwerk nutzt, kann man 6 GPUs als Full Fabric verbinden. Mit nur 4 würde man PCIe verschwenden, mit 8 bliebe außer ein paar USB3-Anschlüssen kaum Spielraum für externe Verbindungen.
    • Der Grund für 6 GPUs ist, dass schneller Storage nötig ist und dieser PCIe-Lanes verwendet.
      Ziel war außerdem, ein 70B-FP16-Modell auszuführen, wofür ungefähr 140 GB VRAM benötigt werden. 6*24 GB = 144 GB, das passt also genau.
    • 6 wirkt vernünftig. Einige der 128 Lanes eines ThreadRipper müssen für Netzwerk und NVMe verwendet werden.
      Vier NVMe-Laufwerke brauchen zum Beispiel x16-Lanes, 10G-Netzwerk noch einmal x4-Lanes.
    • Ich habe mir kürzlich veröffentlichte Unterlagen zu NVIDIA SXM2 angesehen, und SXM2/NVLink 2.0 sah ebenfalls wie ein 6-Way-System aus.
      NVIDIA SXM wurde später auf Version 3 und 4 aktualisiert, und diese Konfiguration basiert nicht einmal darauf, aber vielleicht gibt es noch einen weiteren Grund, warum 6-Way sinnvoll ist.
    • Es wäre schön, wenn du Details zu dem Build teilen könntest, den du im Kopf hast. Unser Labor braucht einen Server, aber es gibt so viele Optionen, dass ich kaum einschätzen kann, was sinnvoll ist.

  • Das sind wirklich gute Nachrichten. Da ich in der Wissenschaft bin, kenne ich mehrere Labore, die Systeme mit mehreren 4090-Karten gebaut haben und nicht wussten, dass Nvidia P2P-Kommunikation zwischen den Karten blockiert hatte.
    Das war auch einer der Gründe, warum ich keine 4090 gekauft habe, obwohl sie für meine Arbeit deutlich günstiger gewesen wäre. Das hier ist zwar kein NVLink, aber da Nvidia NVLink außerhalb der Top-Karten praktisch abgeschafft hat, ist es besser als nichts. Ende letzten Jahres habe ich ein Angebot für vier NVLink-H100 bekommen, mit 13 Monaten Lieferzeit; die Nicht-NVLink-Produkte hätte man in 4 Monaten bekommen können. Inzwischen habe ich vier L40S gekauft, um das Labor am Laufen zu halten, aber Lieferkettenprobleme und massive Preiserhöhungen machen Forschung extrem schwierig. Für sechs Doktoranden und mehrere Studierende reicht das bei Weitem nicht.
    Von 2015 bis 2018 konnten wir an meiner früheren Uni Systeme mit zwei GPUs und NVLink für 5.000 Dollar pro Stück bauen und jedem Studierenden eines unter den Schreibtisch stellen; damals war es viel einfacher.

    • Schon davor hat Nvidia unser Leben schwerer gemacht, indem sie Blower-Designs für Consumer-Karten, die man in Server einbauen konnte, schrittweise abgeschafft haben.
      Aus Sicht eines Labors würde man wahrscheinlich jederzeit eine Karte wählen, die ein Viertel kostet, selbst wenn die MTBF nur halb so hoch ist.
    • Wie sehen die Kosten im Vergleich zu GPU-Cloud-Anbietern aus?

  • Was bedeutet P2P hier? Beim Suchen sieht es nach Peer to Peer aus, aber was bedeutet das im Kontext von Grafikkarten?

    • Es bedeutet, dass beim Senden von Daten aus dem Speicher einer GPU an eine andere GPU nicht der System-RAM durchlaufen werden muss. https://xilinx.github.io/XRT/master/html/p2p.html
    • Gemeint ist Shared-Memory-Zugriff zwischen Nvidia-GPUs.
      https://developer.nvidia.com/gpudirect
    • Der genaue Begriff, und der Ausdruck, den man früher meist dafür verwendet hätte, ist Bus Mastering.
    • Ein dummer Begriff. Dann könnte man auch eine RS-232-Verbindung peer to peer nennen.

  • Ich wünschte, mehr Hardware-Unternehmen würden Dokumentation veröffentlichen und den Rest die Community herausfinden lassen.
    Ähnlich wie damals bei frühen IBM-VGA-Karten. Man muss nur nach „Mode X“ suchen oder nach den echten Hardware-Modi statt den BIOS-Modi, sogar 800x600x16. Leider scheinen die meisten lieber jeden Aspekt der Produktnutzung streng kontrollieren zu wollen, um mehr Geld aus ihrer Nutzerbasis herauszuholen. Persönlich denke ich, dass die produktivste Zeit des PCs auch seine offenste Zeit war.

    • Dann könnte man nicht unterschiedlichen Kunden unterschiedliche Preise für dieselbe Hardware berechnen. Das ist nicht für alle ein Vorteil.
    • Wenn ich ein Hardwarehersteller wäre und Software-Sperren für Produktfunktionen nicht funktionieren würden, würde ich stattdessen auf Hardware-Sperren umstellen.
      Dann würden die Produkte schlicht teurer.
    • Offenheit war definitiv großartig, aber tatsächlich nicht zwingend notwendig. Menschen können auch mit geschlossenen Systemen umgehen lernen.
      Adversarial Interoperability war weit verbreitet, und ob es den Herstellern gefiel oder nicht: Per Reverse Engineering brachte man Software zum Laufen. Was früher selten war, heute aber häufig ist, sind Software- und Hardware-Sperren. Kryptografie hätte eine Technologie sein sollen, die uns stärkt, doch am Ende wird sie eingesetzt, um uns aus unseren eigenen Maschinen auszusperren. Wir sitzen nicht mehr am Steuer. Nicht einmal das Betriebssystem betreibt das System noch wirklich. Selbst ein freies Linux-System ist in einem Konglomerat aus proprietärer Firmware und Silizium, das dem Hersteller unbekannt bleibt, nur noch ein „User OS“ und eher ein kleines Bauteil, das von der eigentlichen Funktion sandboxed wird.
    • Nvidias Software ist ihr Burggraben.

  • Die ursprüngliche Begründung, die Nvidia für die Entfernung von NVLink aus der Consumer-Reihe anführte, war, dass PCIe 5 schnell genug sein werde.
    Die 40xx-Serie kam dann aber ohne PCIe 5 und ohne P2P-Unterstützung auf den Markt. Es ist gut, dass jetzt wenigstens die Hälfte davon nachgereicht wird, aber ich kann mir kaum vorstellen, dass sie das in der Firmware der nächsten Generation weiter erlauben werden.

  • Ist das eine der Funktionen, die bei Consumer-Karten zur Marktsegmentierung deaktiviert wurden?

    • Bis zu einem gewissen Grad ja
      Als nicht ganz perfekte Analogie: Stell dir ein kleines Viertel mit etwa 15 Häusern vor, das gerade gebaut wird. Normalerweise stellt man an die Ecke einen 200-kVA-Transformator und bezieht aus dem Stromnetz eine angemessene Leistung. Wegen Transformatormangels installiert der Bauunternehmer aber einen kommerziellen 1250-kVA-Transformator. Er könnte viel mehr Häuser versorgen als nötig und läuft daher mit reichlich Reserve. Eines Tages will ein Bewohner eine große Plantage starten und findet heraus, wie er diese zusätzliche Trafokapazität nur für sein Haus „aktivieren“ kann. Genau dieser „Aktivierung“ entspricht das, was geohot gefunden hat
    • Das wird vermutlich viele Downvotes geben, aber ich fände, solche Praktiken bei Consumer-Geräten sollten verboten oder sehr hoch besteuert werden
    • Es gibt überhaupt keinen Anreiz, diese Funktion in Consumer-GPUs zu implementieren und zu testen. Multi-GPU-Konfigurationen fürs Gaming haben praktisch nie wirklich zuverlässig funktioniert

  • Ich war schon immer beeindruckt von George Hotz’ Hacking-Fähigkeiten. Sie haben mich auch für eigene Projekte stark inspiriert

    • Es ist wirklich interessant, seinen Entwicklungsprozess zu verfolgen. Auch seine Großzügigkeit, das so zu teilen, ist erwähnenswert
      Er hängt oft an oberflächlichen, beliebigen Problemen fest, die für einen kenntnisreicheren Engineer weniger schwierig wirken würden. Man sieht ihn auch oft wirklich schlechten oder sogar falschen Code schreiben. Die Twitter-Szenen sind ein gutes Beispiel. Trotzdem arbeitet er sich allein beharrlich durch, iteriert immer weiter und erzielt ebenso häufig erstaunliche Verbesserungen. Ein gutes Beispiel, von dem man lernen kann
    • Seine Streams haben mich stark motiviert. Fokus und Einsatz sind der Kern guter Ergebnisse, und mit einer klaren Vision und Strategie kann man sogar Erfolg erreichen
      Glückwunsch an geohot und alle Contributors von tinygrad/comma
    • Er hat eine Konzentrationsfähigkeit wie ein Militärpilot auf einem Langstreckenflug
    • Sein Xbox-360-Laptop war ein zentraler Motivationsfaktor in meiner Teenagerzeit

  • Beim Überfliegen des README: Für alle, die sich fragen: Das ist nicht NVLink, sondern P2P über PCIe

    • RTX 40 hat kein NVLink auf dem PCB, aber einige Karten derselben Familie unterstützen es, also dürfte es im Silizium vorhanden sein. Ich vermute, es wurde per Fuse deaktiviert
    • Soweit ich weiß, unterstützt die 4090 kein PCIe 5.0 und ist daher auf PCIe-4.0-Geschwindigkeit begrenzt. Trotzdem ist es eine Verbesserung

  • In künftigen Architekturen werden sie anfangen, das in der Firmware zu sperren; solange es hält, ist es gut

    • Stimmt, aber das wäre ohnehin irgendwann passiert
      Also ist es besser, es wenigstens für eine Generation nutzen zu können, als es gar nicht zu haben

  • Ich frage mich, ob George das selbst gemacht hat oder ob es jemand war, der auf das von tinycorp ausgesetzte Kopfgeld aus war
    Und an jemanden, der sich mit dem PCI-Subsystem gut auskennt: Sieht das nicht eher so aus, als hätte NVIDIA dem keine Beachtung geschenkt, statt aktiv versucht zu haben, es zu verhindern?

    • PCI-Geräte konnten schon immer einen gemeinsamen Adressraum lesen und schreiben. Zwar unterliegen sie den Einschränkungen der IOMMU, aber normalerweise wurde das vor allem für DMA in den System-RAM verwendet und war nicht darauf beschränkt
      Daher ist es plausibel, das Gerät so zu konfigurieren, dass der gesamte VRAM in den Adressraum eingeblendet wird. Dafür braucht es Unterstützung für resizable BAR oder eine ausreichend große BAR fester Größe. Ebenso plausibel ist es, eine Karte anzuweisen, Adressen zu lesen und zu schreiben, die auf den VRAM einer anderen Karte gemappt sind. Ich frage mich, ob die PCIe-Switching-Kapazität zum Flaschenhals wird oder eher die Punkt-zu-Punkt-Links und der VRAM. So oder so dürfte es helfen, den Roundtrip über den System-RAM zu reduzieren
    • Der Commit läuft auf geohots Namen, also sieht es so aus, als hätte George es selbst gemacht
    • Im tinygrad-Discord hat er den Fortschritt ebenfalls dokumentiert