GPU-Kernel-Treiber mit Rust schreiben: Kurze Einführung in die Funktionsweise von GPU-Treibern

• Dieser Beitrag beleuchtet den Entwicklungsprozess von Tyr, dem modernen, in Rust entwickelten GPU-Treiber für den Linux-Kernel, und die Funktionsweise von GPU-Treibern.
• In der GPU-Treiberentwicklung werden anhand des Beispiels VkCube die Rollenverteilung und Interaktion von UMD (User-Mode-Treiber) und KMD (Kernel-Mode-Treiber) erläutert.
• Der UMD wandelt High-Level-APIs in Low-Level-Kommandos um, die von der GPU verstanden werden können; der KMD übernimmt Kernaufgaben wie Speicherzuweisung, Job-Scheduling und Geräteinitialisierung.
• Die von Tyr bereitgestellte API ist identisch mit Panthor und besteht aus Geräteabfragen, Speichermanagement, Gruppenverwaltung, Job-Submit und Tiler-Heap-Management.
• Im nächsten Beitrag werden die Arm CSF-Hardwarearchitektur und zentrale Komponenten (z. B. die MCU) sowie der Boot-Vorgang behandelt.

---

Einführung: Entwicklung eines modernen GPU-Kernel-Treibers auf Rust-Basis

• Dieser Beitrag ist der zweite Artikel der Reihe über Tyr, den hochmodernen GPU-Kernel-Treiber in Rust für Arm Mali CSF unter Linux.
• Als praktisches Beispiel wurde VkCube, ein einfaches 3D-Programm, das mit der Vulkan API einen rotierenden Würfel rendert, gewählt, um den internen Ablauf eines GPU-Treibers zu erklären.
• Die schlichte Struktur von VkCube eignet sich besonders gut, um die Funktionsweise von GPU-Treibern zu studieren.

Grundlagen von GPU-Treibern: Rollen und Struktur von UMD und KMD

• Besteht aus User Mode Driver (UMD) und Kernel Mode Driver (KMD)
  • UMD: implementiert APIs für normale Anwendungen wie Vulkan und OpenGL, etwa panvk (Mesa Vulkan-Treiber)
  • KMD: wie Tyr als privilegierter Kernel-Level-Treiber, der als Teil des Linux-Kernels läuft
• Der Kernel-Mode-GPU-Treiber verbindet einen weitreichenden UMD mit der eigentlichen GPU; der UMD interpretiert API-Befehle in Befehlssätze, die von der GPU ausgeführt werden können.
• Der UMD bereitet für die Szenen­zusammensetzung benötigte Daten wie Geometrie, Texturen und Shader vor und fordert den Speicher auf der GPU beim KMD an, bevor die Ausführung startet.
• Shader sind eigenständige Programme, die auf der GPU laufen; in VkCube übernehmen sie Funktionen wie Würfelplatzierung, Color Mapping und Rotation. Für die Shader-Ausführung werden externe Daten benötigt (z. B. Geometrie, Farbe oder Rotationsmatrix).
• Der UMD übergibt vorbereitete Befehle (z. B. VkCommandBuffers) an den KMD zur Ausführung und kann bei Fertigstellung benachrichtigt werden, um Ergebnisse im Speicher abzulegen.

KMD (Kernel-Mode-Treiber): Hauptverantwortung

• Zuordnung und Mapping des GPU-Speichers (mit isolation pro Anwendung)
• Job-Submit auf Hardware-Queues und Benachrichtigung des Benutzers bei Abschluss
• In asynchronen, parallelen Hardware-Umgebungen ist das Management von Abhängigkeiten essenziell; um korrekte Ergebnisse sicherzustellen, übernimmt der KMD die Aufgaben Scheduling und Dependency-Validierung.
• Dazu gehören auch Geräteinitialisierung, Betrieb der Takt-/Spannungsregler, Ausführung des Startcodes und Verwaltung der Zugriffsgerechtigkeit, damit mehrere Clients die Hardware fair nutzen.

Wo die Komplexität liegt: Arbeitsteilung zwischen UMD und KMD

• Die Hauptkomplexität von GPU-Treibern liegt beim UMD
  • UMD: wandelt High-Level-API-Kommandos in Hardware-Kommandos um
  • KMD: stellt grundlegende Funktionen bereit wie Speichervisolierung, Sharing und faire Zugriffssteuerung, damit der UMD korrekt arbeiten kann.

Struktur der Treiber-Schnittstelle (API), die Tyr bereitstellt

• Die Tyr-Treiber-API (= entspricht Panthor) lässt sich in fünf Hauptgruppen einteilen
  1. Geräteabfrage: DEV_QUERY (IOCTL zur Abfrage von GPU-Hardwareinformationen, Nutzung des ROM-Bereichs)
  2. Speicherzuweisung und Isolation: VM_CREATE, VM_BIND, VM_DESTROY, VM_GET_STATE, BO_CREATE, BO_MMAP_OFFSET usw.
  3. Management von Scheduling-Gruppen: GROUP_CREATE, GROUP_DESTROY, GROUP_GET_STATE (ausführliche Erklärung folgt in einem Folgebeitrag)
  4. Job-Submit: GROUP_SUBMIT (Ausführungsanfrage an die GPU über Geräte-Befehlspuffer)
  5. Tiler-Heap-Verwaltung: TILER_HEAP_CREATE, TILER_HEAP_DESTROY (Deckung des Speicherbedarfs von Tiled-Rendering-GPUs)
• Diese APIs sind im direkten Sinne weit entfernt von der eigentlichen Pixel-Ausgabe; der UMD übernimmt die tatsächliche Befehlsausführung, während der KMD nur diese Schnittstelle für den Hardwarezugriff bereitstellt.

Fazit und weitere Schritte

• In diesem Beitrag wurde die Gesamtstruktur und der interne Ablauf eines GPU-Treibers sowie die zentralen APIs von Tyr betrachtet.
• Auf Basis dieser Inhalte werden in den Folgebeiträgen die Arm CSF-Hardwarearchitektur, der Microcontroller Unit (MCU) und der Initialisierungsablauf des Treibers behandelt.