Ape ist eine neue offene Softwareimplementierung von Vulkan ICD.

Präsentiert neues Experiment Vulkan-Treiber Ape — eine offene Software-Implementierung des Vulkan ICD, die fast vollständig in Zig geschrieben ist und keinen Code von Mesa verwendet. Das Projekt strebt bislang nicht nach industrieller Verwendung: Der Autor beschreibt es direkt als einen Lehrversuch, einen Treiber "von Hand zu erstellen" und warnt davor, Ape in ernsthaften Projekten zu verwenden. Der Code ist unter der MIT.

Lizenz veröffentlicht worden. Interesse an Ape entstand, nachdem eine separate Vendor-ID für und eine Driver-ID für Ape ApeSoft in die Spezifikationvon Vulkan aufgenommen wurde. Der entsprechende Pull-Request im Repository der KhronosGroup/Vulkan-Docs wurde am 6. Juni 2026gemergt. In einem Kommentar gab der Autor an, dass er an einem Amateur-Vulkan-Treiber arbeitet und sich dem Bestehen aller Vulkan 1.0-Tests nähert.

Im Wesentlichen ist Ape kein Treiber für eine bestimmte Grafikkarte, sondern ein softwarebasierter Vulkan-Renderer, der in seiner Funktionalität Mesa Lavapipe ähnlich ist: Vulkan-Befehle werden durch die eigene Implementierung ausgeführt, ohne auf den Hardware-GPU-Treiber zurückzugreifen. Dabei basiert Ape nicht auf Mesa und ist als eigenständige Codebasis in Zig geschrieben.

Was Ape bereits kann

• Funktioniert als Vulkan ICD.
  Ape wird als Installable Client Driver — das heißt, wie ein Treiber, der über den Standard-Vulkan-Lader über das ICD-Manifest geladen werden kann. Nach dem Bau schlägt der Autor vor, den Vulkan-Lader auf die entsprechende Manifest-Datei hinzuweisen. Dies verwandelt das Projekt von einer einfachen Experimentalsammlung in eine echte Vulkan-Treiber-Implementierung, auch wenn es sich um eine Lehrversion handelt. Der Vulkan-Lader ist darauf ausgelegt, mehrere ICD-Treiber im System zu erkennen und zu verbinden.

• Vollständig in Zig geschrieben.
  Die Hauptcodebasis von Ape ist in Zig geschrieben; auf der Hauptforge-Seite des Projekts ist die Sprache angegeben als Zig 99,9%. Phoronix hebt hervor, dass das Projekt nicht von Mesa abhängt und speziell in Zig und nicht in C/C++ implementiert wurde. Grafische Treiber werden traditionell in C/C++ geschrieben, und Ape zeigt, dass Vulkan ICD auch in einer moderneren Systemprogrammiersprache umgesetzt werden kann.

• Es gibt eine Softwareimplementierung von ApeSoft.
  Im Projekt wird eine Softwareimplementierung Softhervorgehoben, die innerhalb der Treiber-Codebasis selbst existiert. Sie verwendet einen eigenen SPIR-V-Interpreter und einen eigenen Renderer. Ape akzeptiert nicht nur Vulkan-Aufrufe, sondern versucht auch selbständig, Shader und Rendering auf der CPU durchzuführen.

• Die Erstellung wird über Zig build unterstützt.
  Für die softwaretechnische Umsetzung wird im README beschrieben, wie das Team mit "zig build soft" erstellt. Danach müssen Sie den Vulkan Loader mit dem ICD-Manifest konfigurieren. Aktuell ist dies eindeutig ein Werkzeug für Entwickler und Enthusiasten, nicht ein Paket, das einfach "installieren und starten" kann.

• Ein erheblicher Teil von Vulkan 1.0 wurde implementiert.
  Im README finden Sie eine Liste des Status der Vulkan 1.0-Funktionen. Zu den implementierten Funktionen gehören die Erstellung von Instanzen und Geräten, die Speicherzuweisung, Puffer, Bilder, Befehls-Puffer, Render-Pass, Framebuffer, Grafik-Pipeline, Compute-Pipeline, Shader-Module, Deskriptor-Sets, Swapchain und grundlegende Zeichenbefehle. Mit dem Umfang der implementierten Funktionen hat das Projekt bereits die "Hello Triangle"-Experimente hinter sich gelassen, aber es muss noch überprüft werden und die unerledigten Punkte geschlossen werden, um den Status eines vollwertigen kompatiblen Treibers zu erreichen.

• Es gibt Zeichen- und Compute-Befehle.
  In der Liste der implementierten Funktionen sind vkCmdDraw, vkCmdDrawIndexed, vkCmdDrawIndirect, vkCmdDrawIndexedIndirect, vkCmdDispatch und vkCmdDispatchIndirect aufgeführt. Ape deckt nicht nur die grundlegende Infrastruktur von Vulkan ab, sondern auch zwei Schlüssel-API-Szenarien: grafische Darstellung und Berechnungspipelines.

• Swapchain und Ausgabe über Wayland werden unterstützt.
  Im Status der Implementierung sind vkCreateSwapchainKHR, vkQueuePresentKHR, vkCreateWaylandSurfaceKHR sowie die Überprüfungen der Unterstützung der Wayland-Präsentation vermerkt. Das Vorhandensein einer Swapchain und einer Wayland-Oberfläche deutet darauf hin, dass der Treiber nicht nur auf Offline-Tests, sondern auch auf die Ausgabe von Bildern in eine echte Linux-Fensterumgebung abzielt.

• Teile des WSI für X11 und Windows sind derzeit in Bearbeitung.
  vkCreateXcbSurfaceKHR, vkCreateXlibSurfaceKHR, vkCreateWin32SurfaceKHR und die entsprechenden Funktionen zur Überprüfung der Präsentationsunterstützung sind als WIP gekennzeichnet. Wayland ist bereits vorhanden, während die Unterstützung für X11/Windows noch nicht ausgereift ist.

• Einige Elemente von Vulkan 1.0 sind derzeit noch nicht verfügbar oder werden nicht unterstützt.
  In der WIP-Statusliste sind unter anderem vkCreatePipelineCache, vkCreateSemaphore, vkGetQueryPoolResults, vkMergePipelineCaches, Teile der dynamischen Zustände und Timestamp-Befehle aufgeführt. Sparse-Funktionen wie vkQueueBindSparse und vkGetImageSparseMemoryRequirements sind als nicht unterstützt gekennzeichnet. Ape ist in Bezug auf die Abdeckung nah an Vulkan 1.0, ist jedoch noch kein universeller Ersatz für einen vollständigen Vulkan-Treiber.

• Es gibt neue Fortschritte bei der Rendering- und Synchronisationstechnologie.
  Im Verlauf des Projekts wurden am 5.–6. Juni Änderungen verzeichnet, wie etwa die Hinzufügung von einem primitiven Neustart, integeren Textursampling sowie die Verwaltung von mip/lod bei der Abtastung und der Umsetzung von binären Semaphoren. Das Projekt entwickelt sich aktiv in Richtung praktischer Kompatibilität mit Vulkan-Tests und realen Grafikszenarien.

• Das Projekt hat nicht das Ziel der Leistungssteigerung.
  Der Autor betont ausdrücklich, dass Ape für das Studium von Vulkan geschaffen wurde und nicht darauf abzielt, ein leistungsstarker oder produktionsbereiter Treiber zu sein. Ape sollte als Forschungsprojekt, als Lernimplementierung von Vulkan und als Experiment mit Zig betrachtet werden, nicht als Konkurrent von Mesa RADV, ANV, NVK oder Lavapipe.

Zusammenfassend ist Ape nicht interessant, weil man es morgen anstelle von Mesa einsetzen könnte, sondern weil es eine eigenständige Implementierung von Vulkan ICD in Zig mit einem eigenen SPIR-V-Interpreter, einem Software-Renderer und bereits bemerkbarem Deckungsbereich für Vulkan 1.0 darstellt. Für normale Benutzer gibt es bisher kaum Nutzen, doch für Treiberentwickler, Runtime-Autoren und diejenigen, die die interne Funktionsweise von Vulkan studieren, wirkt das Projekt wie ein faszinierender lebendiger Experimentierfeld.

Quelle: linux.org.ru