- Ein Demo-Projekt wurde veröffentlicht, in dem eine einzige in Rust geschriebene Codebasis auf CUDA, Vulkan (SPIR-V), Metal, DirectX 12, WebGPU und CPU sowie damit auf allen wichtigen GPU- und CPU-Plattformen läuft
- Bisherige GPU-Programmierung ist durch die Nutzung separater Sprachen wie GLSL und HLSL komplex und erzeugt Duplizierung, doch diese Demo unterstützt alle GPU-Ziele allein mit reinem Rust-Code
- Als zentrale Implementierungen werden die Projekte Rust GPU (SPIR-V), Rust CUDA (NVVM IR) und Naga (Transformationsschicht für GPU-Sprachen) zusammengeführt – derselbe Bitonic-Sort-Algorithmus läuft auf CPU und allen GPUs, und Sprachfeatures von Rust wie no_std, bedingte Kompilierung, Newtype, Enum und Trait lassen sich auch im GPU-Code unverändert nutzen
- Zwar bleiben noch Verbesserungsaufgaben wie die offizielle rustc-Integration, Debugging und API-Konsistenz, doch der Versuch markiert einen Wendepunkt für plattformübergreifendes GPU-Computing
Umsetzung von plattformübergreifendem GPU-Computing auf Basis von Rust
Projektvorstellung und Bedeutung
- Mit einer einzigen Rust-Codebasis wird derselbe Kernel-Code auf CUDA (NVIDIA), Vulkan (SPIR-V), Metal (Apple), DirectX 12 (Windows), WebGPU (Browser) und CPU ausgeführt
- Ohne dedizierte Shader- oder Kernel-Sprachen wie GLSL oder HLSL kann reiner Rust-Code dieselben Berechnungen auf GPU und CPU ausführen
- Das reduziert Codeduplizierung und Komplexität zwischen GPU und CPU erheblich und bringt die Werkzeug- und Sprachvorteile des Rust-Ökosystems wie Typensicherheit, Tests, Dokumentation und Build-Management auch in die GPU-Programmierung
Hintergrund
- Klassische GPU-Programmierung erfordert je nach Plattform spezialisierte Shader-Sprachen wie GLSL, HLSL, MSL oder WGSL
- Dadurch werden CPU- und GPU-Code getrennt, was zu duplizierter Logik und höherer Entwicklungskomplexität führt
- Die Rust-Community verfolgt als Antwort darauf den Ansatz, normales Rust für GPU-Ziele zu kompilieren
- Rust GPU: kompiliert Rust-Code nach SPIR-V und läuft auf Vulkan- sowie SPIR-V-kompatiblen GPUs
- Rust CUDA: kompiliert Rust-Code nach NVIDIA-CUDA-IR (NVVM IR, PTX) und führt ihn auf CUDA aus
- Naga: eine Zwischenschicht, die Konvertierungen zwischen verschiedenen GPU-Sprachen (WGSL, SPIR-V, GLSL, MSL, HLSL) unterstützt und vor allem im wgpu-Projekt verwendet wird. Sie übernimmt die Portabilität des Backends
- Die Projekte starteten unabhängig voneinander und unterschieden sich in API und Struktur, doch durch jüngere Zusammenarbeit wurde die GPU-Ausführung einer gemeinsamen Codebasis möglich
Implementierungsansatz
- Im Demo-Beispiel wird ein Bitonic-Sort-Algorithmus als einzelner Rust-Code implementiert, und derselbe Code läuft auf allen GPU- und CPU-Zielen
- Wichtige Begriffe der Komponenten
- Host: auf der CPU laufender Rust-Code, der die Arbeit startet
- Device: GPU/CPU, auf der der Kernel tatsächlich ausgeführt wird
- Driver API: Low-Level-APIs wie CUDA, Vulkan, Metal oder DX12 zur Kommunikation mit dem Gerät
- Backend: stellt in Rust eine Abstraktion über die Driver API bereit (cust, ash, wgpu usw.)
- Über Rust-Feature-Flags und Zielkombinationen lassen sich Backend-Auswahl und Build steuern
- Zum Beispiel gibt es pro Backend wie wgpu, ash oder cuda eigene Build-Optionen
- Es ist auch eine Struktur möglich, bei der mehrere Backends in ein einziges Binärprogramm gebaut und zur Laufzeit dynamisch ausgewählt werden
Ablauf der Kernel-Kompilierung
- Je nach Ziel und Feature werden GPU-Ausführungsbinärdateien (SPIR-V, PTX usw.) beim Build erzeugt und in Objektdateien eingebettet
- Zur Laufzeit werden die eingebetteten Kernel geladen, über Naga in das je Plattform benötigte Format umgewandelt und anschließend ausgeführt
- Beispiele:
- macOS: SPIR-V wird in MSL umgewandelt → Ausführung über Metal
- Windows: SPIR-V wird in HLSL umgewandelt → Ausführung über DX12
- Linux/Android: SPIR-V → Ausführung über Vulkan
- CUDA: PTX wird nach SASS kompiliert, auf die GPU geladen und ausgeführt
Rust-freundliche GPU-Coding-Techniken
-
no_std-Unterstützung
- Da auf der GPU kein OS-Support vorhanden ist, ist die Nutzung von Rust
no_std zwingend
- Weil das grundlegende Rust-Ökosystem eingebettete Systeme, Firmware und Kernel-Umgebungen ohne OS von Haus aus berücksichtigt, kann auch die GPU in Rust ohne separaten „Sondermodus“ auf standardmäßige Weise unterstützt werden
-
Bedingte Kompilierung
- Mit
cfg-Attributen und Feature-Flags lässt sich Code für Plattformunterschiede sowie GPU/CPU-Unterschiede klar und kompakt schreiben
- IDE und Compiler verstehen alle Codepfade, was hohe Code-Zuverlässigkeit und Produktivität ermöglicht
-
Einsatz von Newtype
- Implizite Indizes oder Struct-Mappings, bei denen auf der GPU leicht Fehler passieren, lassen sich mit Newtypes auf Typebene absichern
- Mit dem Attribut
#[repr(transparent)] ist Typabstraktion ohne nennenswerten Overhead möglich
-
Enum und sichere Darstellung
- Statt Magic Numbers werden Rust-Enums verwendet; mit
#[repr(u32)] ist die Zuordnung zu nativen Ganzzahlen sichergestellt
- Pattern Matching und Exhaustiveness (Behandlung aller Fälle) ermöglichen eine sichere Code-Struktur
- Wenn Enum-Werte jedoch über gemeinsam genutzte Buffer zwischen CPU und GPU ausgetauscht werden, muss darauf geachtet werden, dass alle Werte gültige Enums sind
-
Trait-basierte generische Algorithmen
- Über Traits lassen sich GPU-Operationen wie Vergleich, Umwandlung und Berechnung für unterschiedliche Werttypen gemeinsam abstrahieren
- Durch klar definierte Trait Bounds in generischen Algorithmen werden Type Safety und Optimierung zugleich erreicht
-
#[inline] und Performance-Optimierung
- Mit
#[inline] wird angestrebt, dass Abstraktionsschichten im tatsächlichen Kompilat verschwinden
- Mit Blick auf GPU-Eigenschaften wie Performance-Anforderungen oder knappen Stack ist das so entworfen, dass Abstraktion keine Kosten verursacht
-
Struct-Kombination und semantische Gruppierung
- Komplexe GPU-Parameter werden nach Bedeutung in Structs gebündelt, was Typensicherheit schafft und eine Explosion an Parametern verhindert
- Mit dem Smart-Constructor-Pattern lassen sich ungültige Zustände bereits während der Kompilierung ausschließen
-
Speicherlayout und Kontrolle über #[repr(C)]
- Für Datenkompatibilität mit der GPU wird das Struct-Layout mit
#[repr(C)] explizit festgelegt
- Es wird erwähnt, dass künftig weitere Sprachunterstützung nötig ist, etwa zur automatischen Behandlung von Padding je GPU
-
Pattern Matching
- Als erweiterte Form von Switch/Case kann es alle Verzweigungen und Zustände im GPU-Code klar behandeln
- Der Compiler kann Codepfade prüfen und Performance optimieren
-
Generische Funktionen
- Dieselbe Logik lässt sich für viele Typen unabhängig vom Datentyp implementieren
- Trait Bounds und Monomorphisierung verbessern Wartbarkeit und Testbarkeit
-
Derive-Makros
- GPU-taugliche Traits wie Copy, Clone, Debug, PartialEq und Pod lassen sich automatisch implementieren
- Das erhöht die Sicherheit und reduziert Boilerplate-Code
-
Modulsystem und Workspace-Verwaltung
- Mit dem Paket- und Modulsystem von Rust lassen sich Host-Code, Kernel, Typen und backend-spezifische Quellen strukturieren
- Cargo workspace und workspace dependency sorgen für konsistente Abhängigkeiten zwischen Crates und erleichtern die Wartung
-
Formatierung, Linting und Dokumentation
- GPU-Code kann mit Rust-Standardwerkzeugen wie rustfmt und clippy auf exakt dieselbe Weise verwaltet werden, wodurch konsistente Qualität erhalten bleibt
- Auch GPU-Code lässt sich mit Doc-Comments und
cargo doc dokumentieren
-
Build-Skripte
- Über Cargo-
build.rs können feature-flag-basierte Kernel-Builds und das Einbetten von Binärdateien automatisiert werden
-
Unit-Tests und Entwicklerproduktivität
- GPU-Kernel-Code kann auch auf der CPU getestet werden, was Entwicklung und Fehlersuche erleichtert
- Traditionelle Werkzeuge wie
println-Debugging und gdb/lldb können verwendet werden
- Vulkan-Kernel lassen sich mit Software-Treibern wie SwiftShader und lavapipe auch in CI testen
- Tests, Code-Coverage-Messung und Property-based Testing lassen sich reibungslos mit Drittanbieter-Tools integrieren
Unvollständige Developer Experience und offene Aufgaben
- Da GPU-Backends nicht in den offiziellen Rust-Compiler integriert sind, werden separate Codegen-Backends (
spirv, nvvm) und festgelegte Nightly-Versionen benötigt
- Das CUDA-Ziel hängt von NVIDIAs LLVM 7.1 ab und erfordert auf aktuellen Linux-Distributionen einen separaten Build
- Es gibt Defizite bei Kernel-Build und Debugging sowie bei Error-Tracing und Debug-Informationen
- Unterschiede bei API und Benennung der Standardbibliothek zwischen Rust GPU und Rust CUDA sorgen für Verwirrung
- Langfristig sind mehr Konsistenz und Integration rund um GPU-Unterstützung in Rust und dem gesamten Ökosystem nötig
Beteiligung der Community und Zukunft
- Die Ausführung desselben Codes in Rust auf allen wichtigen GPU-Plattformen wurde realisiert
- Als nächste Aufgaben bleiben Verbesserungen bei Build und Debugging, der Ausbau von Rust-Sprach- und API-Unterstützung sowie Performance-Tuning
- Entwicklerinnen und Entwickler, die teilnehmen oder beitragen möchten, sollten die GitHub-Repositories von rust-gpu und rust-cuda konsultieren
1 Kommentare
Hacker-News-Kommentar
Es ist wirklich beeindruckend, dass diese Technik überhaupt möglich ist.
Aber mein Anwendungsfall ist die Ausführung auf beliebiger Client-Hardware, daher vertraue ich nicht gern allen Abstraktionsschichten, die über GPU-APIs aufgebaut sind.
Das Ziel ist, die Low-Level-Details der GPU maximal auszunutzen, und Ansätze, die solche Details als lästig ansehen, führen zu Bugs und Leistungseinbußen.
Denn jedes Ziel unterscheidet sich auf sinnvolle Weise.
Um das zu überwinden, müsste ein ähnliches System direkt von den Anbietern bereitgestellt werden.
Aber weil sich die Hersteller weiterhin nicht einig sind, scheinen die Unterschiede zwischen den Plattformen groß zu bleiben.
In bestimmten Fällen gibt es Ausnahmen wie Angle, aber auch dort wird Stabilität nur durch Funktionseinschränkungen erreicht, was letztlich Leistung kostet.
Trotzdem ist es klar hilfreich, dass Ansätze wie bedingte Kompilierung möglich sind.
Rust ist eine Systemprogrammiersprache, daher kann man so viel Kontrolle haben, wie man möchte.
Wir planen, die Details und APIs der GPU in der Sprache und den core/std-Bibliotheken abzubilden und GPU- sowie Treiberfunktionen über das
cfg()-System offenzulegen.(Ich bin der Autor.)
Ich sehe das genauso.
Ich bin immer vorsichtig, etwas Kommerzielles auf Abstraktionsschichten, Adaptern und Übersetzungsebenen aufzubauen, von denen man nicht weiß, ob sie künftig ausreichend unterstützt werden.
Es ist fast 2025, und ich habe immer noch das Gefühl, dass wir dringend einen Open Standard brauchen, der von allen Anbietern unterstützt wird und die vollständigen Fähigkeiten moderner GPU-Hardware nutzbar macht.
Dass die Lage so ist und Nvidia, das die stärksten Software-Einstiegshürden geschaffen hat, ausgerechnet den Vorsitz bei Khronos innehat, wirkt vielsagend.
Da dir Performance wichtig zu sein scheint, wollte ich aus Neugier fragen.
Für mich wirkt der aktuelle Zustand im GPU-Bereich dem früheren CPU-Bereich ziemlich ähnlich.
Bei CPUs gab es eine dreistufige Compiler-Struktur: Optimierung in einer Zwischenschicht und dann Ausgabe von Code für die jeweilige Hardware in der letzten Schicht.
Der Vorteil dieser Struktur ist, dass die Abstraktionsschicht langlebig ist und der Compiler mit der Zeit immer klüger wird.
Ich frage mich, ob so eine Struktur auch bei GPUs möglich ist.
Oder ist die Vielfalt der GPUs so groß, dass das unmöglich oder unwirtschaftlich wäre, oder ist das eigentlich die Richtung, in die es ohnehin geht, nur noch nicht vollständig umgesetzt?
Das stimmt genau.
Ich sehe nicht so recht, was daran besser sein soll, Rust auf Nvidia-GPUs auszuführen als bestehenden CUDA-Code.
Ich verstehe die zusätzliche Abstraktion, aber am Ende wirkt es wie „irgendwie alles Mögliche können“.
Eigentlich ist alles eine Abstraktion.
Auch CUDA ist letztlich nur eine Abstraktion, die in Wirklichkeit völlig unterschiedliche Hardware konzeptionell vereinheitlicht.
Ich entwickle native Audio-Apps, und dort zählt jeder Rechenzyklus.
Außerdem brauche ich nicht nur Grafikshader, sondern vollständige Compute-APIs.
Ich frage mich, ob die Pipeline „Rust -> WebGPU -> SPIR-V -> MSL -> Metal“ aus Performance-Sicht robust ist.
Es sind einfach zu viele Übersetzungsschritte, daher wirkt das fragil und unvorhersehbar.
Bei „... -> Vulkan -> MoltenVk -> ...“ ist es ähnlich.
„Julia -> Metal“ hingegen überspringt MSL und kann spezielle Optimierungen von Apple Silicon wie Unified Memory direkt nutzen.
Die Innovation hier ist nicht die Shader-Sprache, sondern dass man eine vollwertige Programmiersprache wie Rust verwendet.
Rust unterstützt viele Funktionen wie newtype, trait und macro.
Bei der Verwendung von rust-gpu muss man die WebGPU-Schicht nicht zwingend durchlaufen.
rust-gpu ist ein Codegen-Backend des Compilers.
Die Struktur erlaubt es, Rust-MIR direkt nach SPIRV zu kompilieren.
Ist die Pipeline „Rust -> WebGPU -> SPIR-V -> MSL -> Metal“ in Bezug auf die Performance robust?
Im Grunde ist das ein ähnliches Konzept wie Apples Clang-Optimierungsansatz für GPUs.
SPIR-V ist eine Zwischenrepräsentation wie das in LLVM verwendete IR und kann daher systemabhängig optimiert werden.
Theoretisch kann man damit mit einer Codebasis alle unterstützten Raster-GPUs ansprechen.
Der Stack Julia -> Metal ist dagegen vergleichsweise weniger portabel.
Für plattformgebundene Entwickler wie bei Audio-Plugins mag das egal sein, aber für plattformübergreifende Firmen wie u-he oder Spectrasonics könnte eine komplexe SPIR-V-basierte Pipeline attraktiver sein.
Für numerische Berechnungen und deren nachgelagerte Optimierung ist Julia viel besser geeignet als Rust als Systemsprache.
Wenn man sich die Kompatibilitätsmatrix von Rust-CUDA ansieht, erkennt man, dass die Nachfrage nach Rust für CUDA-Programmierung sehr gering ist.
Die meisten Funktionen, die Leute an CUDA mögen, fehlen, und wenn es echte Nachfrage gäbe, hätte es deutlich größere Fortschritte gegeben.
CUDA-Programmierer scheinen wenig Interesse daran zu haben, Rust zu verwenden.
https://github.com/Rust-GPU/Rust-CUDA/blob/main/guide/src/features.md
Auch wenn ich wie du Code habe, den ich gern auf einer GPU ausführen würde, ist alles an GPU-Programmierung so schmerzhaft, dass ich es am Ende doch nicht mache.
Vielleicht ist der eigentliche Nutzen von rust-gpu, CPU-Entwickler zu GPU-Entwicklern zu machen, selbst wenn man dafür gewisse Performance-Verluste in Kauf nimmt.
Wer sich bereits gut mit GPUs auskennt und cuda/vulkan/metal/dx in- und auswendig beherrscht, wird solche Tools vermutlich nicht besonders attraktiv finden.
Ich bin nur ein einfacher Webentwickler, daher ist das vielleicht eine dumme Frage, aber ich habe noch nie GPU-Programmierung gemacht.
WebGPU ist doch eine einzelne API, die mit allen GPU-Backends kompatibel ist — löst das nicht all diese Probleme?
WebGPU scheint auch eines der unterstützten Backends zu sein; falls ja, setzt man dann nicht einfach noch eine weitere Abstraktion auf bestehende Abstraktionen und ruft am Ende doch wieder native GPU-Backends auf?
Nein.
WebGPU ist eine API, mit der die CPU die GPU steuert, um Shader auszuführen und verschiedene Grafikaufgaben zu erledigen, ähnlich wie D3D, Vulkan oder SDL GPU.
Rust-GPU ist eine Sprache, mit der sich Shader-Code schreiben lässt, der tatsächlich auf der GPU läuft, ähnlich wie HLSL, GLSL oder WGSL.
Als Microsoft Einfluss hatte, gab es DirectX.
Aber heute weiß ich nicht, in welchem Maß GPU-Hersteller jeweils dedizierte APIs für ihre eigenen Technologien implementieren.
Es gibt viele besondere Funktionen wie DLSS, MFG, RTX usw.
Wenn man ein Bösewicht aus einem Zeichentrickfilm wäre, könnte man bestehende APIs absichtlich langsam machen und nur neue, schnellere herstellerspezifische APIs performant anbieten.
Zur Einordnung: Ich bin auch Webentwickler und weiß es nicht genau, aber zumindest werden LLMs auf diese Inhalte trainiert.
WebGPU ist eher eine kleinste gemeinsame API.
Der Zed-Editor zielt auf dem Mac zum Beispiel direkt auf Metal.
Und auch darüber, was „gemeinsam“ eigentlich bedeutet, gibt es unterschiedliche Ansichten.
Wie bei OpenGL vs. Vulkan versuchen mächtige Anbieter, ihre eigenen Ökosysteme wie CUDA, Metal oder DirectX zum Marktstandard zu machen.
Wenn es wirklich so einfach wäre, hätte CUDA heute nicht diese enorme Schutzmauer für Nvidia.
Dieses Projekt baut wesentlich auf der Arbeit an der WebGPU-Implementierung wgpu-rs auf.
WebGPU ist für native Apps nicht optimal.
Es wurde auf Basis älterer Vulkan-Versionen entworfen, insbesondere vor RTX, und die späteren nativen APIs haben sich seitdem deutlich weiterentwickelt.
Es ist noch ziemlich roh, aber ich kann kaum glauben, dass so etwas überhaupt möglich ist.
Wenn sich diese Entwicklung fortsetzt, könnte sie das starke Vendor-Lock-in bei GPU-Software aufbrechen und echten Wettbewerb zwischen Hardware-Anbietern ermöglichen.
Ich stelle mir vor, dass irgendwann einmal Machine-Learning-Modelle in Rust geschrieben und sowohl auf Nvidia als auch auf AMD ausgeführt werden könnten.
Natürlich müsste man für maximale Performance weiterhin herstellerspezifischen Code schreiben, aber das ist eine Frage der Optimierung.
Trotzdem könnte man portable Kernel verwenden, die plattformübergreifend laufen.
Es gibt ein Rust-Machine-Learning-Framework namens https://burn.dev mit verschiedenen Backends wie CUDA und ROCm.
Das könnte einen Blick wert sein.
Eine Zukunft, in der man Machine-Learning-Modelle in Rust schreibt und auf Nvidia und AMD gleichermaßen ausführt, halte ich in den nächsten zehn Jahren für schwierig.
Realistisch betrachtet basiert das gesamte Ökosystem mit jax, torch usw. auf Python.
Alle Entwickler in der Praxis auf Rust-Tools umzustellen, ist kaum vorstellbar.
Wenn man die Abstraktionsschichten zählt:
Damit existieren mindestens sechs versteckte Ebenen von Komplexität.
Ich frage mich, ob es möglich ist, all diese Ebenen zu durchdringen und plattformspezifische Eigenheiten in der Performance vollständig abzubilden.
Was rust-gpu letztlich tut, ist, nach SPIRV zu kompilieren, also in das IR von Vulkan.
Deshalb kann man die Ebenen 2 und 3 überspringen oder als parallele Struktur beibehalten.
Tools aus dem Rust-Entwicklungsökosystem wie cargo, cargo test, cargo clippy und rust-analyzer lassen sich auch für die Entwicklung von GPU-Shadern direkt nutzen.
Ich glaube ehrlich gesagt nicht, dass GPU-Programmierung deshalb schwer ist, weil die GPU-Architektur so fremdartig wäre, sondern weil das gesamte Ökosystem an Herstellerabhängigkeit und veralteten Tools krankt.
Die Demo ist sicher eher eine komplexe Rube-Goldberg-Maschine, aber das liegt daran, dass so etwas zum ersten Mal möglich ist.
Mit der Zeit wird es natürlicher und integrierter werden.
Und ein weiterer Vorteil des Rust-Ökosystems ist, dass man so abstrakt oder so konkret entwickeln kann, wie man möchte.
Zum Beispiel kann man mit
std::archplattformspezifische Funktionen nutzen oder sogar Assembler schreiben.Man kann auch Allocators und Panic-Handler austauschen, und wenn die kommende Funktion externally implemented items aktiviert wird, dürfte die Flexibilität im Umgang mit Abstraktionsschichten noch weiter steigen.
Guter Punkt.
Aber die Ebenen 4 bis 6 existieren bei Shader- oder CUDA-Code immer.
Auch die Ebenen 1 und 3 werden in Wirklichkeit nur durch andere Schichten ersetzt, besonders bei plattformübergreifender Entwicklung.
Selbst wenn dieses Rust-Projekt eine zusätzliche Abstraktionsschicht hinzufügt, ist es vielleicht nur eine einzige Ebene mehr.
Und als jemand, der praktisch mit den Ebenen 4 bis 6 arbeitet, kann ich bestätigen, dass dort ebenfalls enorme versteckte Komplexität steckt.
Ehrlich gesagt kommen oft noch mehr Ebenen dazu :P
Realistisch gesehen werden die meisten Nutzer höchstens mit Ebene (3) oder (4) arbeiten.
Tatsächlich kommt also keine besonders große zusätzliche Stufe hinzu.
Übrigens gibt es auch oberhalb von Ebene 6 weitere Abstraktionsschichten.
Firmware und Mikroarchitektur implementieren den Befehlssatz, den wir zu kennen glauben.
Ich denke, das unterscheidet sich nicht besonders davon, für verschiedene CPU-Architekturen unterschiedliche Compiler und Laufzeitumgebungen zu betreiben.
Es gibt unterschiedliche Calling Conventions, Unterschiede in der Endianness, und auf Hardware-Ebene auch Firmware und Microcode.
Es ist wirklich erstaunlich, dass bestehende
no_std- undno alloc-Crates auf GPUs fast ohne Änderungen laufen.Das eröffnet gefühlt wirklich viele Anwendungsideen.
Wirklich großartig.
Die Liste der Rust-GPU-Projekte ist inzwischen schon enorm lang.
Dieses hier ist näher an einer Low-Level-Abstraktion als burn, und burn ist wiederum näher am Low Level als candle.
Jetzt scheint nur noch zu fehlen, ein Backend wie naga zu den übergeordneten Projekten hinzuzufügen.
Es wirkt ein wenig so, als würden alle auf unterschiedlichen Grundlagen etwas bauen, aber das liegt wohl daran, dass die Arbeit an naga relativ neu ist.
Ich möchte noch ergänzen, dass burn sich auf Plattformunterstützung konzentriert.
Andererseits scheint das einzige Backend, das naga verwendet, wgpu zu sein.
Wäre es dann nicht letztlich ausreichend, einfach nur wgpu zu verwenden?
Kurz gesagt: entweder wgpu/ash (vulkan, metal) oder cuda.
Noch ein Zusatz: ein weiteres Crate, das dieser Arbeit nahesteht:
https://github.com/tracel-ai/cubecl
[0]: https://github.com/tracel-ai/burn
[1]: https://github.com/huggingface/candle/
Dort ist auch etwas zu CubeCL zusammengestellt.
Ich bin mir nicht sicher, ob hier wirklich „Rust“ auf der GPU läuft.
Wenn ich den Code grob überfliege, wirkt es wie Rust-Syntax mit sehr vielen Programmiersmakros, auf die am Ende doch eine Shader-Sprache aufgesetzt wird.
GPU-Programmierung ist so andersartig, dass sie besondere Vorsicht erfordert.
Wenn man hier Abstraktion einführt, könnten bestimmte Optimierungen unmöglich werden.
Ich freue mich wirklich über dieses Projekt.
Es hilft Entwicklern enorm, die nicht in Plattformkämpfe hineingezogen werden wollen.
Beispiele wie https://github.com/cogentcore/webgpu sind ebenfalls gut.
Ich verwende Golang und möchte einfach nur auf allen Plattformen die GPU gut nutzen können, und dank solcher Entwicklungen kann man GPUs überall einsetzen.
Vielen Dank an Rust.