ZLUDA, ein Open-Source-Projekt, das CUDA-Apps auf AMD-GPUs ausführt

 (cgchannel.com)
3 Punkte von GN⁺ 2024-03-06 | 1 Kommentare | Auf WhatsApp teilen
  • ZLUDA 3 ist eine Open-Source-Technologie, die für NVIDIA-GPUs entwickelte und an CUDA gebundene Anwendungen unverändert auf AMD-GPUs ausführen soll
  • Das Projekt begann als Drop-in-Ersatzimplementierung von CUDA für Intel-GPUs, doch nachdem die Evaluierungen durch Intel und AMD eingestellt wurden, wurde nun Code für AMD-GPUs veröffentlicht
  • In Blender gibt es Fälle mit einer Performance ähnlich dem nativen HIP-Backend, während 3DF Zephyr und RealityCapture unter ZLUDA als „much slower“ gekennzeichnet sind – die Unterschiede je nach App sind also groß
  • Es wurde bestätigt, dass NVIDIA-exklusive CG-Apps wie RealityCapture und Arnold grundsätzlich laufen können, doch die OptiX-Unterstützung bleibt unter Linux minimal, was Rendering-Workflows einschränkt
  • Ohne Unterstützung von Intel oder AMD ist das Projekt praktisch nahe an „realistically now abandoned“, und auch die NVIDIA-SDK-Lizenz beschränkt die Entwicklung von Übersetzungsschichten für Nicht-NVIDIA-Plattformen

Das CUDA-Abhängigkeitsproblem, das ZLUDA 3 lösen will

  • ZLUDA 3 ist ein Open-Source-Projekt, das für NVIDIA-GPUs entwickelte GPU-basierte Anwendungen auf Hardware anderer Hersteller ausführen soll
  • Es ist darauf ausgelegt, bestehende Anwendungen ohne Änderungen auf neuer Hardware laufen zu lassen, und verlangt von App-Entwicklern keine zusätzliche Portierungsarbeit
  • ZLUDA wurde 2020 erstmals als Drop-in-Ersatzimplementierung von CUDA für Intel-GPUs veröffentlicht; nach Version 2 im Jahr 2021 wurde die Weiterentwicklung schwierig
  • 2021, als Andrzej Janik bei Intel arbeitete, evaluierte Intel ZLUDA als offiziellen Technologiekandidaten, kam aber zu dem Schluss, dass es „keinen Business Case dafür gibt, CUDA-Anwendungen auf Intel-GPUs auszuführen“
  • Nachdem Janik Intel 2022 verlassen hatte, wandte er sich an AMD; auch AMD evaluierte ZLUDA zwei Jahre lang, entschied sich aber gegen eine weitere Fortführung
  • Danach wurde der aktualisierte Code als Open Source veröffentlicht; weitere Hintergründe finden sich im Phoronix-Artikel

In CG-Apps bestätigter Funktionsumfang

  • ZLUDA 3 zielt darauf ab, GPU-Apps, die mit NVIDIAs CUDA-API entwickelt wurden, auf AMD-GPUs auszuführen
  • In den Bereichen VFX, Motion Graphics und Visualisierung gibt es Fälle, in denen einige zentrale CG-Apps und Renderer CUDA-basiert sind und damit faktisch NVIDIA-exklusiv bleiben
  • AMDs HIP ist eine Technologie, um CUDA-Apps auf AMD-Hardware zu portieren, erfordert aber Arbeit durch die Softwareentwickler
    • HIP wird für AMD-kompatible Versionen von Redshift und Blenders Cycles genutzt
    • Auch ZLUDA 3 basiert auf HIP, das Ziel ist jedoch die unveränderte Ausführung bestehender CUDA-Apps
  • Zu der NVIDIA-exklusiven Software, die Janik mit ZLUDA getestet hat, gehören 3DF Zephyr, RealityCapture und Autodesk Arnold
  • Die Arnold-Unterstützung hat den Status eines Proof of Concept; die Zahl der Szenen, die mit ZLUDAs OptiX-Implementierung erfolgreich gerendert wurden, ist begrenzt

Praktische Grenzen bei Performance und Kompatibilität

  • Janik bewertet die Ausführung von CUDA-Apps auf AMD-GPUs als „near-native performance“
  • Laut Phoronix-Benchmarks und einem Thread im Blender-Artists-Forum gibt es in Blender Fälle, in denen die ZLUDA-Performance ähnlich dem nativen HIP-Backend ist
  • Demgegenüber kennzeichnet das ZLUDA-GitHub-Repository 3DF Zephyr und RealityCapture unter ZLUDA als much slower
  • Viele GPU-Renderer nutzen neben CUDA auch NVIDIA OptiX für Raytracing-Beschleunigung
    • ZLUDAs OptiX-Unterstützung ist auf einem „minimum“-Niveau
    • OptiX-Unterstützung gibt es nur unter Linux, nicht unter Windows
    • Der Implementierungsstand ist „buggy, unoptimized and incomplete“
    • ZLUDA-OptiX ist nicht in den redistribuierbaren Versionen enthalten und muss selbst gebaut werden
  • Ob andere CUDA-basierte CG-Apps lauffähig sind, lässt sich ohne Nutzertests nur schwer beurteilen

Projektfortführung und Lizenzbeschränkungen

  • Janik sieht ZLUDA ohne Unterstützung von Intel oder AMD als „realistically now abandoned“ an
    • Er ist offen für Vorschläge, die das Projekt voranbringen
    • Andernfalls wird er wohl nur Unterstützung für NVIDIA-Technologien hinzufügen, die ihn persönlich interessieren, etwa DLSS
    • Auch der aktuelle Code kann für Softwareentwickler nützlich sein, die eine schrittweise Portierung von CUDA nach HIP vornehmen
  • Laut einem Update vom 14. März 2024 wies Tom’s Hardware darauf hin, dass die Bedingungen der NVIDIA-SDK-Lizenz verbieten, SDK-Artefakte einschließlich des CUDA Toolkits für die Entwicklung von Übersetzungstechnologien für Nicht-NVIDIA-Plattformen zu verwenden
  • Kompilierte Versionen von ZLUDA 3 sind für Windows und Linux verfügbar; der Quellcode steht unter Apache 2.0 oder der MIT license
  • ZLUDA 3 herunterladen kann man über das GitHub-Repository des Projekts

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-06
Meinungen auf Hacker News

  • Es gab schon vor 22 Tagen eine entsprechende Diskussion: AMD habe eine auf ROCm basierende Drop-in-Implementierung von CUDA finanziert, die anschließend als Open Source veröffentlicht wurde; der Beitrag [0] bekam 400 Kommentare.
    Der bemerkenswerte Top-Level-Kommentar in diesem Thread besagte, dass die Veröffentlichung selbst eine Folge davon war, dass AMD die Finanzierung eingestellt hatte: „Nach zwei Jahren Entwicklung und Prüfung kam AMD zu dem Schluss, dass das Ausführen von CUDA-Anwendungen auf AMD-GPUs wirtschaftlich nicht sinnvoll ist. Eine der Bedingungen meines Vertrags mit AMD war, dass ich veröffentlichen darf, falls AMD entscheidet, dass es für eine weitere Entwicklung nicht geeignet ist. So sind wir also bei heute angekommen.“ Quelle: https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
    [0] https://news.ycombinator.com/item?id=39344815

  • Dass AMD die Finanzierung dieses Projekts gestrichen hat, ist wirklich absurd. Denn sobald es als Open Source veröffentlicht wurde, begann es, Wert für AMD-Nutzer zu schaffen.
    Genau so etwas sollte eigentlich AMDs oberste Priorität sein, stattdessen hielt man sich jahrelang mit zwei, inzwischen vielleicht drei, kaum unterstützten alternativen APIs auf.

    • Sobald das zu einer vertrauenswürdigen Option wird, wird Nvidia sofort eine Unterlassungsaufforderung schicken und klagen. Als ernsthafte Lösung ist es eine Sackgasse; in diesem Kontext ist es also nachvollziehbar.
    • Vielleicht wollten sie die Leute dazu bringen, HIP zu verwenden.
      „HIP ist sehr schlank und hat gegenüber direkter Programmierung im CUDA-Modus kaum oder gar keine Auswirkungen auf die Performance.“
      „Das HIPIFY-Tool wandelt CUDA-Quellcode automatisch in HIP um.“
      1. https://github.com/ROCm/HIP
    • Strategisch betrachtet ist schwer zu sehen, dass dies für AMD das Beste gewesen wäre. Wenn es nicht produktreif und rechtlich abgesichert ist, ist es nur ein Tool, mit dem Entwickler Anwendungen auf AMD entwickeln und dann auf Nvidia ausliefern können.
      Bei Consumer-Grafikkarten könnte das kurzfristig nützlich sein, langfristig wäre es aber eher ein Eigentor, das Nvidias Position im Rechenzentrum weiter zementiert.
    • Sehr wahrscheinlich haben sie vorab von NVIDIAs Ankündigung erfahren und diesen Auftragnehmer freigegeben. Den Vertragsbedingungen zufolge wäre das Projekt Open Source geworden.
    • Hier liegt die Annahme zugrunde, dass AMD sich entschieden hat aufzugeben. Vielleicht arbeiten sie ja an etwas Besserem?

  • Zu dieser Diskussion scheint auch der Beitrag zu passen, dass „Nvidia die Nutzung von Übersetzungsschichten untersagt hat, um CUDA-Software auf anderen Chips auszuführen“ [1].

    [1] https://news.ycombinator.com/item?id=39592689

    • Wenn man keine Nvidia-Hardware nutzt, keine Nvidia-Treiber nutzt und nie Nvidias EULA zugestimmt hat, verstehe ich nicht, warum einen das kümmern sollte.
      Emulation ist sowohl ausdrücklich als auch nach der Rechtsprechung rechtlich geschützt. Die Nachbildung von APIs zu Kompatibilitätszwecken ging bis vor den Supreme Court der USA, und es wurde entschieden, dass sie nicht urheberrechtlich geschützt ist. Zumindest gilt das wohl in einem ziemlich weiten Rahmen.
      Ich bin kein Anwalt, aber ich sehe nicht recht, auf welche rechtliche Grundlage Nvidia setzen will. Für Einzelpersonen oder Unternehmen, die keinerlei Nvidia-Hardware haben, wirkt das wie ein irrelevanter Punkt. Wenn ein Unternehmen bereits Nvidia-Hardware besitzt, könnte Nvidia zwar bis zu einem gewissen Grad argumentieren, aber fällt das dann nicht erst recht direkt in den Bereich wettbewerbswidrigen Verhaltens?
    • Ich sehe nicht, worin sich das von Wine/Proton unterscheidet. In der Microsoft-EULA dürfte es ähnliche Bedingungen geben; wenn sie durchsetzbar wären, hätte Microsoft den Wine-Entwicklern dann nicht genauso Unterlassungsaufforderungen geschickt?
    • Man sollte noch einmal betonen, dass diese Klausel entgegen der Aussage des Artikels seit Januar 2022 in der CUDA-EULA stand und entgegen dem Update des Artikels auch im Download enthalten war.
    • Spielt das eine Rolle? Man braucht nicht die Erlaubnis von irgendjemandem, um ein System zu implementieren, das eine kompatible Schnittstelle zu einem anderen System hat.
      Man würde zwar gegen die EULA verstoßen, aber solange man keine CUDA-Software herunterlädt, muss man der EULA auch nicht zustimmen, und die ZLUDA-Autoren konnten das vermutlich vermeiden.
    • NVIDIA hat dazu kein Recht. Hier ist kein NVIDIA SDK beteiligt.

  • Dass „auch Intel am Ende zu dem Schluss kam, dass es wirtschaftlich nicht sinnvoll ist, CUDA-Anwendungen auf Intel-GPUs auszuführen“, ist schon ziemlich bitter.

    • Kurz gesagt: Jedes Unternehmen, das eine gewisse Größe und ein gewisses Alter erreicht hat, träumt nicht mehr davon, ein Wettbewerber zu sein, sondern davon, ein Monopolist zu sein.
    • Intels Grafiksparte war so schlecht, dass man wegen des schlechten Eindrucks, den sie bei den Leuten hinterlassen hatte, den Namen Intel HD aufgeben musste.

  • Eine Tatsache wurde bestätigt, die jeder kennt, der auch nur einmal mit AMD-GPGPU zu tun hatte: Das Einzige, was AMD daran hindert, ein 2-Billionen-Dollar-Unternehmen zu werden, ist wirklich schreckliche Software.
    Ich erinnere mich daran, Bugs im OpenCL-Compiler von AMD gefunden zu haben [1], und es war auch sehr einfach, den OpenCL-Compiler mit einem Segmentation Fault zum Absturz zu bringen. Das wurde nie behoben, also habe ich es aufgegeben, es zu melden.
    Dass AMD keinen CUDA-Konkurrenten entwickelt hat, ist die kurzsichtigste Entscheidung, die ich je gesehen habe. Ich verstehe nicht, warum der Vorstand nicht durch Leute ersetzt wurde, die begreifen, dass niemand die beste Hardware kauft oder nutzt, wenn die Software dafür – sehr freundlich ausgedrückt – erbärmlich ist.
    Wir als Kunden müssen teure Nvidia-Karten kaufen, weil der AMD-Vorstand offenbar zu reich ist, um sich um den Wert von etwa 1 Billion Dollar zu kümmern, den er auf dem Tisch liegen lässt. Wer AMD-Aktien besitzt, sollte Fragen stellen. Dieser Vorstand gehört in den nächsten Abfluss gespült.
    [1] https://github.com/msoos/amdmiscompile -- am Ende wurde das behoben

    • Kannst du mir GPGPU erklären, als würdest du es JavaScript erklären?
      Nach meinem naiven Verständnis ist eine Grafikkarte ein seltsamer Computer, auf den man Befehle und Daten lädt und der dann selbstständig rechnet.
      Ich verstehe nicht, warum CUDA so eine große Sache ist. Kann AMD nicht einfach direkten Zugriff auf seine GPUs geben, als wären sie ein Array aus 4096 Arduino-Boards?
    • Stimmt. Umgekehrt ist AMD im Allgemeinen Open-Source-freundlicher als Nvidia. Nvidia war eine Zeit lang aktiv feindselig; man muss sich nur Linus’ „F* you!“-Video ansehen.
      Firmen, die Hardware entwickeln, sind im Allgemeinen schlecht in Software. Es gibt Ausnahmen, aber nicht viele, und diese Firmen wurden tatsächlich über ihren Aktienkurs belohnt. Ich kenne die Kultur in AMDs Software-Sparte nicht, aber normalerweise braucht es eine ziemlich große Veränderung, um so etwas zu beheben.
      Nur den Vorstand auszutauschen, dürfte das kaum lösen. Wenn Anweisungen des Top-Managements nicht der einzige Faktor sind, der das Unternehmen herunterzieht, müsste man viel mehr Managementebenen ändern und auch etliche mittlere Führungskräfte austauschen. Wenn die Software-Einstellungen nicht richtig gelaufen sind, muss man manchmal sogar einzelne Contributors ersetzen.
    • Ich verstehe nicht, warum AMD nicht mit Intel zusammenarbeitet, um SYCL als Standard für GPGPU und heterogenes Programmieren voranzutreiben.
      Intel ist gut in Software, SYCL ist ein offener Standard, beide Unternehmen könnten vom selben Code profitieren, und Kunden könnten SYCL-Code auf Wunsch auch auf einem Threadripper ausführen. Manche Threadripper sind heutzutage sogar so schnell wie einige GPUs.
      Will AMD sein eigenes proprietäres Lock-in-Ökosystem aufbauen? Ich verstehe nicht, warum sie sich nicht einem plattformübergreifenden offenen Standard verschreiben.
    • AMD Software selbst mochte ich eigentlich ziemlich. Es war einfach, die Framerate auf 60 zu begrenzen, damit die GPU nicht am Limit läuft, wenn ein Spiel oder eine Software das nicht nativ unterstützt, und man konnte auch wie bei Shadowplay ein Instant Replay per Hotkey einrichten, das ständig die letzten Minuten aufzeichnet.
      Als meine UPS nicht gut war, konnte ich auch das GPU-Power-Limit setzen, und um meine RX 580 noch etwa ein Jahr länger zu nutzen, konnte ich automatisches Overclocking aktivieren.
      Allerdings lässt die Software bzw. der Treiber seit etwa 2020 VR-Titel in weniger als einer Stunde abstürzen. Es gibt auch kein Softwarepaket für Linux, und CoreCtrl ist nicht annähernd so gut. Instant Replay funktioniert manchmal einfach nicht. Weder unter Windows noch unter Linux habe ich ROCm jemals ordentlich mit einem lokalen LLM zum Laufen gebracht, und DKMS machte bei jedem apt upgrade gern massenhaft nutzlose Kompilierungen.
      Für meine nächste GPU überlege ich, aus Neugier eine Intel Arc zu nehmen oder einfach zu Nvidia zurückzugehen. Kandidaten wären etwa A580, RX 6600 oder RTX 3050, und vielleicht halte ich auch durch, bis die Preise anderer Komponenten fallen.

  • Gibt es eine Programmiersprache, die in verschiedene Kernel-Sprachen wie Metal, CUDA oder irgendetwas von AMD kompiliert? Falls nicht: warum nicht?
    C-Compiler kompilieren für verschiedene CPU-Architekturen. Sollte es nicht auch Compiler für GPU-Architekturen geben? Vielleicht hat nur noch niemand einen gebaut.

    • Kann man OpenCL dazuzählen?
      https://www.khronos.org/api/opencl
    • OpenMP 5 hat GPU-Unterstützung spezifiziert. Eine kurze Suche legt nahe, dass einige Compiler das inzwischen zumindest teilweise unterstützen.

  • Hat jemand das hier ausprobiert, um Open-Source-Photogrammetrie-Tools wie Meshroom auszuführen? Im Artikel werden einige proprietäre Tools erwähnt, aber mein Bedarf ist ziemlich klein.

  • Das sieht fast genauso aus wie der Fall Oracle gegen Google rund um die Nutzung von JVM-Bytecode.

    • So sieht es für mich nicht aus. Der Streitpunkt ist nicht die Bytecode-Übersetzung, sondern dass geistiges Eigentum an Bibliotheken auf höherer Ebene an Hardware gebunden wird.
      Das ist eher so, als würde Google sagen: „Unsere Android-Anwendungen dürfen nur auf von Google genehmigten Telefonen laufen.“ Soweit ich es verstehe, macht Google das bei Dingen wie dem Play-Framework oder Maps tatsächlich.

  • Ich habe kürzlich ein interessantes Gerücht gehört: Die Person bei NVIDIA, die für CUDA zuständig war, habe jahrelang darum gekämpft, Ressourcen zu bekommen und das Unternehmen davon zu überzeugen, dieses Projekt ernst zu nehmen.
    Ohne CUDA wäre NVIDIA heute ganz sicher nicht annähernd ein 1-Billion-Dollar-Unternehmen.

  • Dass geohot weiter mit teuren AMD-GPUs kämpft, hängt ebenfalls damit zusammen: https://twitter.com/tinygrad/status/1764734675002810622