Ape — neue offene Software-Implementierung des Vulkan ICD

Vorstellung neues experimentelles Vulkan-Treiber Ape — eine open-source Software-Implementierung des Vulkan ICD, die fast vollstĂ€ndig in Zig geschrieben ist und keinen Mesa-Code verwendet. Das Projekt strebt derzeit nicht an, industriell genutzt zu werden: Der Autor beschreibt es offen als einen Ausbildungsversuch, einen Treiber „von Hand zusammenzustellen“, und warnt davor, Ape in ernsthaften Projekten zu verwenden. Der Code wird unter der Lizenz veröffentlicht MIT.


Das Interesse an Ape entstand, nachdem der Spezifikation Vulkan eine separate Vendor-ID fĂŒr Ape und eine Driver-ID fĂŒr ApeSoft. Der entsprechende Pull-Request im KhronosGroup/Vulkan-Docs-Repository wurde gemerged am 6. Juni 2026. Im Kommentar gab der Autor an, dass er an einem Amateur-Vulkan-Treiber arbeitet und sich dem Abschluss 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 Funktion Mesa Lavapipe Ă€hnelt: Vulkan-Befehle werden durch die eigene Implementierung ausgefĂŒhrt, ohne auf den Hardware-GPU-Treiber zuzugreifen. Dabei basiert Ape nicht auf Mesa und ist als eigenstĂ€ndige Codebasis in Zig geschrieben.

Was Ape bereits kann

  • Funktioniert als Vulkan ICD.
    Ape ist als Installable Client Driver formatiert — das heißt, als ein Treiber, der durch den standardmĂ€ĂŸigen Vulkan Loader ĂŒber ein ICD-Manifest erkannt werden kann. Nach dem Kompilieren empfiehlt der Autor, dem Vulkan-Loader die entsprechende Manifestdatei anzugeben. Dies macht das Projekt nicht nur zu einer Sammlung von Experimenten, sondern zu einer richtigen Implementierung eines Vulkan-Treibers, wenn auch einer Ausbildungsimplementierung. Der Vulkan-Loader ist genau darauf ausgelegt, mehrere ICD-Treiber im System zu entdecken und zu verbinden.

  • Komplett in Zig geschrieben.
    Die Hauptcodebasis von Ape ist in Zig geschrieben; auf der Hauptforge-Seite des Projekts wird die Sprache als Zig 99,9%. Phoronix betont besonders, dass das Projekt nicht von Mesa abhÀngt und speziell in Zig und nicht in C/C++ umgesetzt wurde. Grafikkartentreiber werden traditionell in C/C++ geschrieben, und Ape zeigt, dass Vulkan ICDs auch in einer moderneren Systemsprache umgesetzt werden können.

  • Es gibt eine softwarebasierte Implementierung von ApeSoft.
    Im Projekt ist eine softwarebasierte Implementierung Soft, die innerhalb der eigenen Codebasis des Treibers enthalten ist, herausgestellt. Sie verwendet einen eigenen SPIR-V-Interpreter und einen eigenen Renderer. Ape nimmt nicht nur Vulkan-Aufrufe entgegen, sondern versucht auch, Shader und Rendering selbst auf der CPU auszufĂŒhren.

  • UnterstĂŒtzt den Build ĂŒber Zig build.
    FĂŒr die programmgesteuerte Implementierung wird im README beschrieben, wie man mit dem Befehl zig build soft bauen kann. Danach muss der Vulkan-Lader auf das ICD-Manifest konfiguriert werden. Bislang ist dies eindeutig ein Werkzeug fĂŒr Entwickler und Enthusiasten, nicht ein Paket "installiert und lĂ€uft".

  • Ein erheblicher Teil von Vulkan 1.0 wurde implementiert.
    Im README ist eine Liste des Status der Vulkan 1.0-Funktionen zu finden. Zu den implementierten gehören die Erzeugung von Instanzen und GerĂ€ten, das Zuweisen von Speicher, Puffer, Bilder, Command Buffers, Render Pass, Framebuffer, Graphics Pipeline, Compute Pipeline, Shader-Module, Deskriptor-Sets, Swapchain und grundlegende Rendering-Befehle. In Bezug auf die implementierten Funktionen hat das Projekt bereits das "Hello Triangle"-Experiment ĂŒberschritten, muss jedoch noch Tests durchfĂŒhren, um den Status eines voll funktionsfĂ€higen kompatiblen Treibers zu erreichen und unerledigte Punkte zu schließen.

  • Es gibt Rendering- und Compute-Befehle.
    Im Listing der implementierten Funktionen sind vkCmdDraw, vkCmdDrawIndexed, vkCmdDrawIndirect, vkCmdDrawIndexedIndirect, vkCmdDispatch und vkCmdDispatchIndirect vermerkt. Ape deckt nicht nur die grundlegende Infrastruktur von Vulkan ab, sondern auch zwei zentrale API-Szenarien: grafisches Rendering und Berechnungs-Pipelines.

  • Swapchain und Ausgabe ĂŒber Wayland werden unterstĂŒtzt.
    Im Implementierungsstatus sind vkCreateSwapchainKHR, vkQueuePresentKHR, vkCreateWaylandSurfaceKHR und die ÜberprĂŒfung der UnterstĂŒtzung der Wayland-PrĂ€sentation vermerkt. Das Vorhandensein von Swapchain und Wayland-OberflĂ€che bedeutet, dass der Treiber nicht nur auf Offline-Tests abzielt, sondern auch auf die Bildausgabe in eine echte Desktop-Umgebung unter Linux.

  • Ein Teil von WSI fĂŒr X11 und Windows ist noch in Arbeit.
    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 von X11/Windows noch nicht abgeschlossen ist.

  • Einige Elemente von Vulkan 1.0 sind derzeit noch nicht bereit oder werden nicht unterstĂŒtzt.
    Im Status WIP sind unter anderem vkCreatePipelineCache, vkCreateSemaphore, vkGetQueryPoolResults, vkMergePipelineCaches, ein Teil der dynamischen ZustĂ€nde und Timestamp-Befehle aufgefĂŒhrt. Sparse-Funktionen wie vkQueueBindSparse und vkGetImageSparseMemoryRequirements sind als unsupported gekennzeichnet. Ape ist im Hinblick auf die Abdeckung nah an Vulkan 1.0, stellt aber noch keinen universellen Ersatz fĂŒr einen regulĂ€ren Vulkan-Treiber dar.

  • Es wurden frische Verbesserungen beim Rendering und der Synchronisation erzielt.
    In der Projektgeschichte wurden am 5. und 6. Juni Änderungen wie die EinfĂŒhrung von primitive restart, integer texture sampling, Mip-/LOD-Kontrolle bei der Abtastung und die Implementierung binĂ€rer Semaphore vermerkt. Das Projekt entwickelt sich aktiv in Richtung praktischer KompatibilitĂ€t mit Vulkan-Tests und realen grafischen Szenarien.

  • Das Projekt hat nicht das Ziel, die Leistung zu optimieren.
    Der Autor schreibt direkt, dass Ape entwickelt wurde, um Vulkan zu erforschen und nicht darauf abzielt, ein leistungsstarker oder produktionsbereiter Treiber zu sein. Man sollte Ape als Forschungsprojekt, als Lernimplementierung von Vulkan und als Experiment mit Zig betrachten, und nicht als Konkurrenten von Mesa RADV, ANV, NVK oder Lavapipe.

Im Fazit ist Ape interessant, nicht weil man es morgen anstelle von Mesa verwenden 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 Support fĂŒr Vulkan 1.0 ist. FĂŒr gewöhnliche Benutzer bietet es derzeit wenig Nutzen, fĂŒr Treiberentwickler, Laufzeit-Autoren und Personen, die sich mit der inneren Funktionsweise von Vulkan befassen, scheint das Projekt jedoch ein interessantes lebendiges TestgelĂ€nde zu sein.

Quelle: linux.org.ru

60GB SSD 8Gb DDR4