VUDA: Vulkan-Implementierung von CUDA

• VUDA ist eine Header-only-Bibliothek auf Vulkan-Basis, die eine CUDA Runtime API-Schnittstelle zum Schreiben GPU-beschleunigter Anwendungen bereitstellt
• Die Funktionen folgen, soweit möglich, der Spezifikation der CUDA Runtime; für die allgemeine Nutzung kann die Referenzdokumentation zur NVIDIA CUDA Runtime API herangezogen werden
• Auf alle Funktionen kann durch Einbinden von vuda.hpp und Verwendung des vuda::-Namespace zugegriffen werden; vuda_runtime.hpp kapselt und leitet CUDA-Funktionen um
• Der Beispiel-Workflow verwendet CUDA Runtime API-Aufrufe wie cudaSetDevice, cudaMalloc, cudaMemcpy, cudaFree; wenn nicht mit NVCC gearbeitet wird, wird mit vuda::launchKernel("add.spv", "main", ...) ein Vulkan-Shader-Modul ausgeführt
• Als Dokumentationsabschnitte werden Change List, Setup and Compilation, Deviations from CUDA und Implementation Details bereitgestellt

[GN⁺]

Hacker-News-Kommentare

• Es ist keine CUDA-Implementierung, sondern eine Implementierung der CUDA Runtime API
  Diese API wird für die Gerätekonfiguration, Speicherallokation und -kopie sowie zum Starten von Kerneln verwendet
  Wichtig ist: Damit kann man keinen Kernel-Code schreiben, der tatsächlich auf der GPU läuft

  • Ich hatte kurz gehofft, dass das bedeutet, CUDA-Code auf AMD-GPUs ausführen zu können, aber der Beschreibung nach ist das nicht der Fall
  • Dann frage ich mich, wofür das überhaupt nützlich ist
  • Wenn man ein CUDA-Ersatz sein will, braucht man PTX-Unterstützung und Support für die Entwicklung in mehreren Sprachen
    Sonst kommt man bei vielen Workloads gar nicht erst vom Fleck
• 1. Das hier implementiert eine grobe API im C-Stil
     Es gibt auch einen Modern-C++-API-Wrapper mit automatischer Fehlerprüfung, RAII-Ressourcenkontrolle usw.: https://github.com/eyalroz/cuda-api-wrappers
     Zur Einordnung: Ich bin der Autor
  2. Die Runtime API zu implementieren ist nicht die richtige Wahl
     Für Dinge wie Kontextisolierung oder das dynamische Hinzufügen neu kompilierter JIT-Kernel als Module ist die Implementierung der Driver API entscheidend
  3. Dieses Projekt hat nicht einmal 3000 Zeilen
     Um die gesamte zentrale CUDA-API abzudecken, also Driver, Runtime, NVTX, CUDA-C++ und PTX-JIT-Kompilierung, waren mehr als 14.000 Zeilen nötig

• Ich frage mich, wie das zu George Hotz’ Ziel passt, maschinelles Lernen auf AMD-Chips zu ermöglichen und die Nvidia-Dominanz zu brechen
  Ich bin kein Experte, aber dieser Ansatz wirkt stark und wichtig
  Allerdings ist das System so komplex, dass ich bezweifle, dass eine Einzelperson das bauen kann, und es sieht so aus, als bräuchte man zum Start Unterstützung durch Unternehmen
  Vielleicht hätte AMD Interesse daran, direkt Ingenieurskapazität zu finanzieren und das iterativ zu verbessern

  • Hotz spricht nicht nur über User-Space-Bibliotheken, sondern auch über den Treiber

    The software is terrible! There’s kernel panics in the driver. You have to run a newer kernel than the Ubuntu default to make it remotely stable. I’m still not sure if the driver supports putting two cards in one machine, or if there’s some poorly written global state. When I put the second card in and run an OpenCL program, half the time it kernel panics and you have to reboot.
    Er beschäftigt sich zwar auch mit dem User-Space, aber es ist klar, dass er im gesamten Stack ober- und unterhalb solcher Bibliotheken viel Verbesserungsbedarf sieht

  • Ich habe https://www.youtube.com/watch?v=Mr0rWJhv9jU und https://geohot.github.io/blog/jekyll/update/2023/06/07/a-div... gefunden
    Jetzt fühle ich mich mit meinen Erfahrungen mit AMD etwas beruhigter
    Es schien große Probleme mit den GPU-Treibern zu geben, und nun weiß ich, dass ich damit nicht allein war

• Wer auf Windows eine AMD-GPU nutzt und damit Machine-Learning-Modelle trainieren oder ausführen will, sollte sich torch-directml und tensorflow-directml ansehen

  • Ich bin mir nicht sicher, ob DirectML für AMD sinnvoller ist als AMDs Versuch, mit ROCm/MiOpen/HIP CUDA-Kompatibilität nachzubilden
    CUDA und DirectX wirken beide zu Low-Level, um sie als kompatible APIs auf sehr unterschiedlicher Hardware, nämlich AMD und Nvidia, ohne große Leistungseinbußen zu verwenden
    cuDNN ist höher angesiedelt, sodass eher Spielraum besteht, Kompatibilität ohne Leistungsverlust zu bieten, indem man getrennte Kernel-Implementierungen für AMD- und Nvidia-Hardware pflegt
    Allerdings basiert ein großer Teil dessen, was Frameworks wie PyTorch tun, nicht nur auf cuDNN, sondern auf benutzerdefinierten Kerneln
    Für AMD scheint die beste Wahl eine absolut robuste Low-Level-API zu sein, plus Unterstützung für hochoptimierende Machine-Learning-Compiler, damit Framework-Anbieter wie PyTorch, TensorFlow und JAX darauf leicht Support aufbauen können
    Letztlich profitieren davon die Framework-Anbieter, daher sollte AMD sehr eng mit ihnen zusammenarbeiten
    Es ist seltsam, dass AMD die Unterstützung für Machine Learning jahrelang wie eine Nebensache behandelt hat
    Vielleicht hielt man den Consumer-Markt für Machine Learning im Vergleich zu Grafik und Gaming für zu klein, um den Aufwand zu rechtfertigen, aber wie Nvidia gezeigt hat, ist das der Weg zu deutlich profitableren Rechenzentrumsaufträgen
  • Mich würde interessieren, wie gut das in der Praxis funktioniert
    Als ich DirectML zuletzt ausprobiert habe, war die Unterstützung schwach und es gab nur wenig Software dafür
    Auch die Performance sah nicht besonders gut aus
    Inzwischen nutze ich eine Linux-Installation und kann dank ROCm populäre Tools wie Automatic111 webui und oobabooga verwenden
  • Funktioniert das wirklich?
    Wenn AMD zu einem vernünftigen Preis GPUs herausbringt, die Nvidia im Machine Learning schlagen, würde ich vielleicht eine neue GPU kaufen
    Gute Nvidia-GPUs sind einfach zu teuer, um den Kauf zu rechtfertigen

• Sieht nach einem toten Projekt aus
  Der letzte Commit war im Februar 2022

  • Und selbst dieser Commit war nur eine hinzugefügte Zeile
    Der Großteil des Codes ist 3 bis 5 Jahre alt

• Ich frage als jemand, der nie direkt GPUs programmiert hat: Wie verhält sich das im Vergleich zu HIP?
  Könnte es eine effiziente Abstraktionsschicht über Nvidia- und AMD-GPUs hinweg sein?

  • Laut https://news.ycombinator.com/item?id=34399633 ist hipify-clang ein auf clang basierendes Werkzeug, das CUDA-Quellcode in HIP-Quellcode übersetzt
    Es wandelt CUDA-Quellcode in einen abstrakten Syntaxbaum um, dann durchlaufen Transformations-Matcher diesen und geben anschließend HIP-Quellcode aus
    Außerdem gibt es hier eine Liste der von hipify-clang unterstützten CUDA-APIs: https://rocm.docs.amd.com/projects/HIPIFY/en/latest/supporte...

• Von AMD erwarte ich da nichts
  Solche Kompatibilitätswerkzeuge hätten sie schon viel früher bauen müssen

• Solche Projekte tauchen ziemlich regelmäßig auf, gewinnen aber nie wirklich an Fahrt, und ich nutze immer noch Nvidia-GPUs
  Ich glaube nicht, dass das hier groß anders sein wird

• Ziemlich interessant
  Bedeutet das also, dass mein CUDA-beschleunigtes Programm auch auf AMD- und Intel-Geräten laufen können sollte?