spirt

SPIR-?

⋯? ?Ziel ? ?verwandeln? ?übersetzen ⋯?

SPIR-? ist ein Forschungsprojekt, das darauf abzielt, von SPIR-V abgeleitete Shader-orientierte IR-Designs zu erforschen und ein Framework rund um eine solche IR zu erstellen, um erweiterte Kompilierungspipelines zu ermöglichen, die über das hinausgehen, was die vorhandenen SPIR-V-Tools ermöglichen.

Ein solcher Bedarf entstand im Rust-GPU-Projekt, das eine Vielzahl von Legalisierungsdurchgängen erfordert, um Allzweckcode (Rust ¹ ), der auf untypisiertem Speicher läuft, in einen GPU-freundlichen direkten Datenfluss umzuwandeln.
Unser Ziel ist es, die bestehenden Rust-GPU SPIR-V-Legalisierungen durch SPIR- zu ersetzen. Äquivalente - aber noch wichtiger: SPIR-? sollte es ermöglichen, viel leistungsfähigere Legalisierungs-/Optimierungsdurchläufe zu schreiben, was für eine direkte SPIR-V-Manipulation ^{unvorstellbar} gewesen wäre.

---

_{¹ Rust ist in seinen Anforderungen hier nicht einzigartig und mehr Sprachen (oder IRs) könnten irgendwann von einem solchen Framework Gebrauch machen, aber die anfängliche Entwurfs- und Implementierungsarbeit konzentrierte sich auf Rust-GPU}

_{² nicht völlig unmöglich, erfordert aber übermäßige Entwicklungs-/Wartungskosten, muss ständig Korrektheit und Leistung abwägen (konservativere Pässe sind vertrauenswürdiger) usw.}

Haftungsausschluss

Dieses Projekt ist nicht mit der Khronos Group Inc. oder einer ihrer Tochtergesellschaften oder verbundenen Unternehmen verbunden, verbunden, autorisiert, unterstützt oder in irgendeiner Weise offiziell mit ihnen verbunden. Die offizielle Website der Khronos Group Inc. finden Sie unter https://www.khronos.org.
Die Namen SPIR, SPIR-V sowie zugehörige Namen, Marken, Embleme und Bilder sind Marken ihrer jeweiligen Eigentümer.

_{Zusätzlicher Kontext: Der Name dieses Projekts ist ein Wortspiel mit SPIR-V und hat keinerlei Bezug zu SPIR (dem älteren IR-Standard).}

Status

? Dieses Projekt befindet sich in der aktiven Design- und Entwicklungsphase, viele Details können und werden sich ändern ?

Wenn Sie an der Verwendung von SPIR- interessiert sind? Vielleicht möchten Sie zunächst einen Blick auf den Issue-Tracker werfen, um relevante Probleme zu finden, und sogar neue Probleme eröffnen, die Ihren Anwendungsfall beschreiben.
Da der Schwerpunkt zunächst auf dem Anwendungsfall von Rust-GPU liegt, fehlen möglicherweise verschiedene (ansonsten wünschenswerte) Funktionen/APIs/Dokumente oder ändern sich schnell – gleichzeitig gibt es Diskussionen über die Erweiterung des Umfangs und der Benutzerfreundlichkeit von SPIR-? auf lange Sicht sind weiterhin willkommen.

Nicht-Ziele (zumindest kurzfristig)

• Unterstützung des („OpenCL“) Kernel Dialekts von SPIR-V
  • Kernel SPIR-V ist viel näher an LLVM IR als Shader SPIR-V, und daher ist es wahrscheinlicher, dass Tools, die sich an LLVM orientieren, besser passen
• Textsyntax, die zurückgeparst werden kann
  • Das heißt, die Pretty-Printer-Ausgabe ist eine reine Visualisierung

Bisher entworfen und umgesetzt

IR-Datentypen : Ermöglicht nahezu beliebige SPIR-V-Anweisungen für alle nicht erkannten Opcodes IDs werden durch interne/„Entity“-Handles ersetzt (siehe unten) Praktikant für Attribute (Dekorationen & Ähnliches), Typen und Konstanten d. h. automatische Deduplizierung, effiziente Indizierung und kein Konzept der „Definition“ (nur die Verwendung interner Handles kann dazu führen, dass davon ausgegangen wird, dass ein Modul einen bestimmten Typ/eine bestimmte Konstante enthält). „Entitätssystem“ für z. B. Definitionen in einem Modul, Anweisungen in einer Funktion usw. verbietet die Iteration zugunsten/erzwingt die Verwendung einer effizienten Indizierung Strukturierte Kontrollfluss-„Regionen“, inspiriert von RVSDG, strenger als SPIR-V (weitere Einzelheiten finden Sie in der Dokumentation von ControlRegionDef )

Framework-Dienstprogramme : visit / transform : unveränderlicher/veränderlicher IR-Durchlauf print : hübscher Drucker mit (gestylter und verlinkter) HTML-Ausgabe Pässe (nach/von/auf SPIR-?) : spv::lower : „Absenkung“ von SPIR-V, Normalisierung vieler irrelevanter Details Verlustbehaftet für einige relevante Details (dies sind Fehler, obwohl viele nicht semantisch sind und daher eine niedrigere Priorität haben) spv::lift : „Heben“ Sie zurück zu SPIR-V und treffen Sie bei Bedarf willkürliche Entscheidungen vergleichbar mit z. B. der Generierung der GLSL-Syntax aus SPIR-V, nur eine Ebene tiefer cfg::Structurizer : (Re-)Strukturierung, vom willkürlichen Kontrollfluss zu den strenger strukturierten „Regionen“ passes::link : Zuordnung (Verknüpfung) von Importen zu relevanten Exporten

Einfaches Beispiel (mit nicht trivialem Kontrollfluss)

GLSL ( for-loop.vert.glsl ) #version 450 out int output0; void main() { int o = 1 ; for ( int i = 1 ; i < 10 ; i ++ ) o *= i; output0 = o; } WGSL ( for-loop.wgsl ) @vertex fn main() -> @location( 0 ) i32 { var o : i32 = 1 ; for (var i : i32 = 1 ; i < 10 ; i ++ ) { o *= i; } return o; }

SPIR-? #[spv.Decoration.Flat] #[spv.Decoration.Location(Location: 0 )] global_var GV0 in spv.StorageClass.Output: s32 func F0 () -> spv.OpTypeVoid { loop (v0: s32 <- 1s32, v1: s32 <- 1s32) { v2 = spv. OpSLessThan (v1, 10s32): bool (v3: s32, v4: s32) = if v2 { v5 = spv. OpIMul (v0, v1): s32 v6 = spv. OpIAdd (v1, 1s32): s32 (v5, v6) } else { (spv. OpUndef : s32, spv. OpUndef : s32) } (v3, v4) -> (v0, v1) } while v2 spv. OpStore (Pointer: &GV0, Object: v0) }

SPIR-V ( for-loop.wgsl.spvasm ) %typeof_output0 = OpTypePointer Output %i32 %output0 = OpVariable %typeof_output0 Output %typeof_main = OpTypeFunction %void %main = OpFunction %void None %typeof_main %entry = OpLabel OpBranch %bb0 %bb0 = OpLabel OpBranch %bb1 %bb1 = OpLabel %o = OpPhi %i32 %1 _i32 %bb0 %o_next %bb5 %i = OpPhi %i32 %0 _i32 %bb0 %i_next %bb5 OpLoopMerge %bb6 %bb5 None OpBranch %bb2 %bb2 = OpLabel %cond = OpSLessThan %bool %i %10 _i32 OpSelectionMerge %bb4 None OpBranchConditional %cond %bb4 %bb3 %bb3 = OpLabel OpBranch %bb6 %bb4 = OpLabel %o_next = OpIMul %i32 %o %i OpBranch %bb5 %bb5 = OpLabel %i_next = OpIAdd %i32 %i %1 _i32 OpBranch %bb1 %bb6 = OpLabel OpStore %output0 %o OpReturn OpFunctionEnd

Übersicht über die IR-Landschaft der GPU (Shader).

(und die Vision, wie SPIR-? dazu passt)

Hier wird unterschieden zwischen:

• Interchange IRs (Standards, die viele Tools für die Zusammenarbeit verwenden können)
  • SPIR-V war eigentlich als solcher Standard gedacht (außerhalb des GPU-Bereichs ist wasm auch ein gutes Beispiel).
  • Sie müssen lediglich die richtigen Konzepte kodieren und dürfen sich nicht zu weit von dem entfernen, was Tools verstehen. Der Entwurfsaufwand konzentriert sich jedoch häufig auf ein „Serialisierungs“-Format
• Compiler-IRs (nicht standardmäßige Implementierungsdetails von Compilern)
  • LLVM ist ziemlich bekannt, aber Mesas NIR liegt noch näher an SPIR-? (beide sind Shader-orientiert und verfügen über ähnliche spezielle Optionen, z. B. für die Handhabung des Kontrollflusses)
  • Diese müssen mit Legalisierungs-/Optimierungsdurchgängen und im Allgemeinen mit vielen spontanen Transformationen gut zurechtkommen, da ihr Hauptzweck darin besteht, solche Vorgänge zu beschleunigen
  • Hier ist SPIR-? fungiert als eine Art „Verwandter“/Dialekt von SPIR-V, macht aber Kompromisse zugunsten der „Intra-Compiler“-Nutzung

Beitrag

Wir freuen uns über Beiträge der Gemeinschaft zu diesem Projekt.

Weitere Informationen zu den ersten Schritten finden Sie in unserem Leitfaden für Mitwirkende. Bitte lesen Sie auch unsere Bedingungen für Mitwirkende, bevor Sie Beiträge leisten.

Jeder Beitrag, der absichtlich zur Aufnahme in ein Embark Studios-Projekt eingereicht wird, muss dem Rust-Standardlizenzmodell (MIT ODER Apache 2.0) entsprechen und daher wie unten beschrieben doppelt lizenziert sein, ohne dass zusätzliche Bedingungen gelten:

Lizenz

Dieser Beitrag ist unter EITHER OF doppelt lizenziert

• Apache-Lizenz, Version 2.0, (LICENSE-APACHE oder http://www.apache.org/licenses/LICENSE-2.0)
• MIT-Lizenz (LICENSE-MIT oder http://opensource.org/licenses/MIT)

nach Ihrer Wahl.

Der Klarheit halber bezieht sich „Ihr“ auf Embark oder einen anderen Lizenznehmer/Benutzer des Beitrags.