Ape — nouvelle implémentation ouverte de Vulkan ICD

Présenté nouvelle expérience pilote Vulkan Ape — implémentation logicielle ouverte de l'ICD Vulkan, écrite presque entièrement en Zig et n'utilisant pas le code de Mesa. Le projet ne prétend pas encore à une utilisation industrielle : l'auteur le décrit directement comme une tentative pédagogique de « réaliser un pilote manuellement » et avertit de ne pas utiliser Ape dans des projets sérieux. Le code est publié sous une licence MIT.

L'intérêt pour Ape est apparu après que la spécification Vulkan a ajouté un identifiant de fournisseur distinct pour Ape et un identifiant de pilote pour ApeSoft. La demande de tirage correspondante dans le dépôt KhronosGroup/Vulkan-Docs a été fusionnée le 6 juin 2026. Dans le commentaire, l'auteur a indiqué qu'il travaillait sur un pilote Vulkan amateur et qu'il se rapprochait de la réussite de tous les tests Vulkan 1.0.

En essence, Ape n'est pas un pilote pour une carte graphique spécifique, mais un rendu Vulkan logiciel, similaire à Mesa Lavapipe : les commandes Vulkan sont exécutées par sa propre implémentation, sans appel au pilote GPU matériel. Toutefois, Ape n'est pas basé sur Mesa et est écrit comme une base de code autonome en Zig.

Ce que Ape sait déjà faire

• Fonctionne comme un ICD Vulkan.
  Ape est conçu comme un Installable Client Driver — c'est-à-dire comme un pilote qui peut être pris en charge par le chargeur Vulkan standard via un manifeste ICD. Après la compilation, l'auteur propose d'indiquer au chargeur Vulkan le fichier manifeste correspondant. Cela rend le projet non seulement un ensemble d'expérimentations, mais une véritable réalisation de pilote Vulkan, bien que pédagogique. Le chargeur Vulkan est justement conçu pour détecter et connecter plusieurs pilotes ICD dans le système.

• Entièrement écrit en Zig.
  La base de code principale d'Ape est écrite en Zig ; sur la page principale du projet, le langage est indiqué comme Zig 99,9 %. Phoronix souligne en particulier que le projet ne dépend pas de Mesa et est réalisé précisément en Zig, et non en C/C++. Les pilotes graphiques sont traditionnellement écrits en C/C++, et Ape montre que l'ICD Vulkan peut aussi être réalisé sur un langage système plus moderne.

• Il existe une réalisation logicielle d'ApeSoft.
  Le projet met en avant une réalisation logicielle Soft, qui se trouve à l'intérieur même de la base de code du pilote. Elle utilise son propre interpréteur SPIR-V et son propre moteur de rendu. Ape ne se contente pas d'accepter les appels Vulkan, mais cherche à exécuter indépendamment les shaders et le rendu sur le CPU.

• La construction est prise en charge via Zig build.
  Pour la réalisation logicielle, le README indique comment compiler avec la commande zig build soft. Ensuite, il faut configurer le chargeur Vulkan sur le manifeste ICD. Pour l'instant, c'est clairement un outil destiné aux développeurs et aux passionnés, plutôt qu'un package « installé et exécuté ».

• Une partie significative de Vulkan 1.0 a été réalisée.
  Le README fournit une liste de l'état des fonctions Vulkan 1.0. Parmi celles réalisées, on trouve la création d'instances et de dispositifs, l'allocation de mémoire, des tampons, des images, des buffers de commandes, des passes de rendu, des framebuffers, des pipelines graphiques, des pipelines de calcul, des modules de shader, des ensembles de descripteurs, une swapchain et des commandes de rendu de base. En termes de fonctionnalités réalisées, le projet a déjà dépassé l'expérimentation du « triangle hello », mais il lui reste encore à passer des tests et à combler les lacunes pour atteindre le statut de pilote pleinement compatible.

• Des commandes de rendu et de calcul sont disponibles.
  Dans la liste des fonctions réalisées, on note vkCmdDraw, vkCmdDrawIndexed, vkCmdDrawIndirect, vkCmdDrawIndexedIndirect, vkCmdDispatch et vkCmdDispatchIndirect. Ape couvre non seulement l'infrastructure de base de Vulkan, mais aussi deux scénarios clés de l'API : le rendu graphique et les pipelines de calcul.

• La swapchain et la sortie via Wayland sont prises en charge.
  Dans l'état de réalisation, on note vkCreateSwapchainKHR, vkQueuePresentKHR, vkCreateWaylandSurfaceKHR, ainsi que des contrôles de prise en charge de la présentation Wayland. La présence d'une swapchain et d'une surface Wayland signifie que le pilote est destiné non seulement aux tests hors ligne, mais aussi à la sortie d'images dans un environnement de fenêtres Linux réel.

• Une partie du WSI pour X11 et Windows est encore en cours de développement.
  vkCreateXcbSurfaceKHR, vkCreateXlibSurfaceKHR, vkCreateWin32SurfaceKHR et les fonctions associées de vérification du support de présentation sont marquées comme WIP. Wayland est déjà présent, tandis que le support pour X11/Windows n'est pas encore achevé.

• Certains éléments de Vulkan 1.0 ne sont pas encore prêts ou ne sont pas pris en charge.
  Dans l'état WIP, on trouve, par exemple, vkCreatePipelineCache, vkCreateSemaphore, vkGetQueryPoolResults, vkMergePipelineCaches, certaines états dynamiques et des commandes de timestamp. Les fonctions Sparse comme vkQueueBindSparse et vkGetImageSparseMemoryRequirements sont marquées comme non prises en charge. Ape est proche de Vulkan 1.0 en termes de couverture, mais n'est pas encore un remplacement universel pour un pilote Vulkan normal.

• De nouvelles améliorations en matière de rendu et de synchronisation ont été apportées.
  Dans l'historique du projet, des modifications ont été notées les 5 et 6 juin, telles que l'ajout du redémarrage des primitives, de l'échantillonnage de textures entières, de la gestion de mip/lod lors de l'échantillonnage et de la mise en œuvre de sémaphores binaires. Le projet évolue activement dans le sens de la compatibilité pratique avec les tests Vulkan et des scénarios graphiques réels.

• Le projet ne vise pas la performance.
  L'auteur affirme directement qu'Ape est conçu pour explorer Vulkan et n'a pas pour but d'être un pilote performant ou prêt pour la production. On doit considérer Ape comme un projet de recherche, une implémentation éducative de Vulkan et une expérience avec Zig, plutôt que comme un concurrent de Mesa RADV, ANV, NVK ou Lavapipe.

Au final, Ape est intéressant non pas parce qu'il sera demain un remplaçant de Mesa, mais parce que c'est une implémentation autonome de Vulkan ICD en Zig avec son propre interpréteur SPIR-V, un moteur de rendu logiciel et une couverture already visible de Vulkan 1.0. Pour les utilisateurs ordinaires, l'utilité est encore limitée, mais pour les développeurs de pilotes, les auteurs de runtimes et les personnes étudiant l'architecture interne de Vulkan, le projet apparaît comme un laboratoire vivant fascinant.

Source : linux.org.ru