NVIDIA vollzieht den vollständigen Wechsel zu Open-Source-Linux-GPU-Kernelmodulen

• NVIDIA hat im Mai 2022 mit dem R515-Treiber die Linux-GPU-Kernelmodule als Open Source unter einer Dual-Lizenz aus GPL und MIT veröffentlicht
• Damals galt dies für Rechenzentrums-Computing-GPUs, während GeForce- und Workstation-GPUs noch Alpha-Status hatten
• NVIDIA kündigte an, dass in späteren Releases ein stärkerer und vollständigerer Linux-Support für GeForce- und Workstation-GPUs bereitgestellt werde und dass die offenen NVIDIA-Kernelmodule letztlich die geschlossenen Treiber ersetzen würden
• Zwei Jahre später wird mit den Open-Source-GPU-Kernelmodulen eine gleichwertige oder bessere Anwendungsleistung erreicht, und es wurden die folgenden wichtigen neuen Funktionen hinzugefügt:
  • Unterstützung für Heterogeneous Memory Management (HMM)
  • Confidential Computing
  • Kohärente Speicherarchitektur der Grace-Plattform
  • und mehr
• Jetzt ist der richtige Zeitpunkt gekommen, vollständig auf Open-Source-GPU-Kernelmodule umzusteigen, und NVIDIA wird diese Änderung mit dem kommenden R560-Treiber-Release umsetzen

Unterstützte GPUs

• Nicht alle GPUs sind mit Open-Source-GPU-Kernelmodulen kompatibel
• Neuere Plattformen wie NVIDIA Grace Hopper oder NVIDIA Blackwell müssen Open-Source-GPU-Kernelmodule verwenden; proprietäre Treiber werden auf diesen Plattformen nicht unterstützt
• Für neuere GPUs auf Basis der Architekturen Turing, Ampere, Ada Lovelace und Hopper wird der Wechsel zu Open-Source-GPU-Kernelmodulen empfohlen
• Ältere GPUs auf Basis der Architekturen Maxwell, Pascal und Volta sind nicht mit Open-Source-GPU-Kernelmodulen kompatibel und sollten daher weiterhin die proprietären NVIDIA-Treiber verwenden
• Bei Deployments, in denen auf demselben System ältere und neuere GPUs gemischt sind, sollten weiterhin proprietäre Treiber verwendet werden
• NVIDIA stellt ein neues Erkennungshilfsskript bereit, das bei der Auswahl des passenden Treibers hilft. Weitere Details finden sich im Abschnitt „Verwendung des Installationshilfsskripts“ weiter unten in diesem Beitrag

Änderungen am Installer

• Grundsätzlich wird die Standardversion des Treibers, die über alle Installationsmethoden installiert wird, von proprietären Treibern auf Open-Source-Treiber umgestellt. Es gibt einige spezielle Szenarien, die besondere Aufmerksamkeit erfordern:
  • Paketmanager mit CUDA-Metapaket
  • Ausführbare Datei
  • Installationshilfsskript
  • Details zum Paketmanager
  • Windows Subsystem for Linux
  • CUDA Toolkit

Verwendung eines Paketmanagers mit CUDA-Metapaket

• Wenn das CUDA Toolkit mit einem Paketmanager installiert wird und nicht über eine run-Datei, gibt es ein Installations-Metapaket, das üblicherweise verwendet wird. Durch die Installation des Top-Level-Pakets cuda werden das CUDA Toolkit und das zugehörige Treiber-Release gemeinsam installiert.

Verwendung einer ausführbaren Datei

• Wenn CUDA oder der NVIDIA-Treiber über eine .run-Datei installiert wird, fragt das Installationsprogramm die Hardware ab und installiert automatisch den am besten geeigneten Treiber für das System. Über einen UI-Schalter kann auch zwischen proprietären und Open-Source-Treibern gewählt werden.

Verwendung des Installationshilfsskripts

• Wie bereits erwähnt, hat NVIDIA ein Hilfsskript erstellt, das den Auswahlprozess begleitet, falls man unsicher ist, welchen Treiber man für die GPUs des Systems wählen sollte
• Zur Nutzung installiert man zunächst das Paket nvidia-driver-assistant über den Paketmanager und führt anschließend das Skript aus

Details zum Paketmanager

• Für ein konsistentes Erlebnis empfiehlt NVIDIA bei der Installation des CUDA Toolkits und der Treiber die Verwendung eines Paketmanagers. Die konkret verwendeten Paketverwaltungssysteme oder Paketstrukturen können sich jedoch je nach Distribution unterscheiden.
• Dieser Abschnitt erläutert die spezifischen Details, Vorsichtsmaßnahmen oder Migrationsschritte, die für verschiedene Plattformen erforderlich sind.

Windows Subsystem for Linux

• Windows Subsystem for Linux (WSL) verwendet den NVIDIA-Kerneltreiber des hostseitigen Windows-Betriebssystems. Auf dieser Plattform sollte kein spezifischer Treiber installiert werden. Bei Verwendung von WSL sind keine Änderungen oder Maßnahmen erforderlich.

CUDA Toolkit

• Die Installation des CUDA Toolkits bleibt bei Nutzung eines Paketmanagers unverändert. Es reicht, den folgenden Befehl auszuführen:

$ sudo apt-get/dnf/zypper install cuda-toolkit  

Weitere Informationen

• Weitere Details zur Installation des NVIDIA-Treibers oder des CUDA Toolkits finden sich im Abschnitt „Treiberinstallation“ des CUDA-Installationsleitfadens

Meinung von GN⁺

• Dass NVIDIA die GPU-Kernelmodule als Open Source bereitstellt, ist eine sehr positive Veränderung für das GPU-Computing-Ökosystem. Dadurch können Nutzer und Entwickler Probleme im Zusammenhang mit NVIDIA-GPU-Treibern leichter debuggen und beheben.

• Der Wechsel zu Open Source wird Nutzern, die NVIDIA-GPUs in Bereichen wie HPC, AI und Machine Learning einsetzen, mehr Flexibilität und Transparenz bieten. Besonders in Unternehmensumgebungen dürfte dies helfen, Bedenken in Bezug auf Sicherheit und Stabilität beim Einsatz von NVIDIA-GPU-Lösungen zu verringern.

• Allerdings könnten im Zuge des Open-Source-Übergangs Kompatibilitätsprobleme mit bestehenden Anwendungen auftreten, die auf proprietären Treibern basieren. NVIDIA sollte dafür klare Richtlinien und einen Migrationspfad bereitstellen.

• Auch ein Vergleich mit konkurrierenden Open-Source-GPU-Computing-Plattformen wie AMDs ROCm könnte ein spannendes Thema sein. Es ist zu erwarten, dass sich der Wettbewerb im GPU-Computing durch NVIDIAs Open-Source-Wechsel weiter verschärft.

• Es bleibt zu hoffen, dass NVIDIA künftig Beiträge aus der Community aktiv annimmt und die Leistung sowie Stabilität der Open-Source-GPU-Kernelmodule kontinuierlich verbessert. Das dürfte zur weiteren Verbreitung und Innovation im GPU-Computing beitragen.

[bbulbum]

Linus Torvalds: Nvidia! Peng! Danke!

[halfenif]

Ein starkes Wort … F*ck …!

[bbulbum]

Könnte sein, haha

[GN⁺]

Hacker-News-Kommentare

• Ich erinnere mich, dass Nvidia vor einigen Jahren schwer gehackt wurde

  • Die Hacker drohten, alle Daten zu veröffentlichen, wenn die Treiber nicht Open Source gemacht würden
  • Möglicherweise haben die Hacker also bekommen, was sie wollten

• Nvidias Kernel-Module sind in zwei Komponenten aufgeteilt

  • eine vom Betriebssystem unabhängige "OS-agnostic"-Komponente
  • eine für Linux-Kernel-Version und -Konfiguration spezifische "kernel interface layer"-Komponente
  • Wenn sie im Nvidia-.run-Installationspaket enthalten ist, wird die OS-agnostic-Komponente als Binärdatei bereitgestellt

• Die Nutzung von Sway und Wayland mit Nvidia war für mich zu schwierig, deshalb bin ich zu AMD gewechselt

  • Das Hauptproblem war ein inzwischen gelöstes Issue auf gitlab.freedesktop.org

• Ich frage mich, wie die Lage bei Nvidia-Treibern unter Linux derzeit ist

  • Ich habe einen neuen Desktop mit einer AMD-GPU aufgebaut
  • Ich wollte Probleme mit Closed Source oder unzureichenden/veralteten Open-Source-Treibern vermeiden

• Nvidia stellt vollständig auf Open-Source-GPU-Kernel-Module um

  • Oder Nvidia befindet sich gerade in der vollständigen Umstellung auf Open-Source-GPU-Kernel-Module

• Ich hoffe, dass diese Änderung die Installation/Upgrades von Nvidia-Treibern unter Linux einfacher macht

  • Versionskonflikte zwischen Treibern, Utilities und Container-Runtimes zu beheben, war ein Albtraum

• Ein Tarball hinzuwerfen und "Hol's dir!" zu sagen, ergibt keinen Sinn

  • Ich werde weiter AMD kaufen, bis tatsächlich Treiber in den Upstream-Kernel eingebracht werden

• Als skeptischer Mensch, der die Details genau liest, halte ich das für einen guten Schritt

  • Abgesehen davon, dass Nvidias proprietäre Kultur dadurch womöglich weiter gestärkt wird, sehe ich keine Nachteile

• Ich erinnere mich daran, als Linus in die Kamera schaute und Nvidia den Mittelfinger zeigte

  • Ich frage mich, ob diese Zeit inzwischen vorbei ist, ob es Zeit für eine Versöhnung ist oder ob es weiterhin Probleme gibt

• Dass wenigstens die Kernel-Module bereitgestellt werden, ist schon von Bedeutung

  • Wahrscheinlich wird es aber nicht zu Upstream-Beiträgen kommen