Introduced new experimental Vulkan driver Ape — an open-source implementation of Vulkan ICD, mostly written in Zig and not using Mesa code. The project does not yet claim industrial application: the author explicitly describes it as a learning attempt to 'build a driver by hand' and warns against using Ape in serious projects. The code is published under the MIT.
Interest in Ape arose after an individual vendor ID for and driver ID for Ape ApeSoft . The corresponding pull request in the KhronosGroup/Vulkan-Docs repository has been merged. In the comment, the author mentioned that they are working on an amateur Vulkan driver and getting closer to passing all Vulkan 1.0 tests. on June 6, 2026Essentially, Ape is not a driver for a specific graphics card, but rather
a software Vulkan renderer , similar in purpose to Mesa Lavapipe: Vulkan commands are executed by its own implementation, without calling the hardware GPU driver. At the same time, Ape is not based on Mesa and is written as a standalone codebase in Zig.What Ape can already do
Works as a Vulkan ICD.
Ape is structured as
Installable Client Driver — that is, as a driver that can be picked up by the standard Vulkan loader through the ICD manifest. After building, the author suggests specifying the Vulkan loader with the corresponding manifest file. This makes the project not just a collection of experiments, but a real implementation of a Vulkan driver, albeit a learning one. The Vulkan loader is designed to detect and connect multiple ICD drivers in the system. Completely written in Zig.The main codebase of Ape is written in Zig; on the main forge page, the language is indicated as
Zig 99.9% . Phoronix particularly emphasizes that the project is not dependent on Mesa and is implemented specifically in Zig, not in C/C++. Graphics drivers are traditionally written in C/C++, but Ape shows that a Vulkan ICD can also be implemented in a more modern system language.There is a software implementation of ApeSoft.The project includes a software implementation
Soft , which is located within the driver’s codebase itself. It uses its ownSPIR-V interpreter and its own renderer. Ape not only accepts Vulkan calls but also attempts to execute shaders and rendering on the CPU independently. Building is supported via Zig build.Assembly through Zig build is supported.
The README specifies the method for building with the zig build soft command for software implementation. After this, you need to configure the Vulkan loader with the ICD manifest. So far, this is clearly a tool for developers and enthusiasts, rather than a simple 'install and run' package.A significant portion of Vulkan 1.0 has been implemented.
The README contains a list of the Vulkan 1.0 function statuses. Among the implemented features are instance and device creation, memory allocation, buffers, images, command buffers, render pass, framebuffer, graphics pipeline, compute pipeline, shader modules, descriptor sets, swapchain, and basic drawing commands. In terms of implemented functions, the project has already progressed beyond the 'hello triangle' experiment, but it still needs to undergo testing and finalize outstanding elements to achieve full compatible driver status.There are drawing and compute commands.
The implemented function list includes vkCmdDraw, vkCmdDrawIndexed, vkCmdDrawIndirect, vkCmdDrawIndexedIndirect, vkCmdDispatch, and vkCmdDispatchIndirect. Ape covers not only the basic infrastructure of Vulkan but also two key API scenarios: graphics rendering and compute pipelines.Support for swapchain and output through Wayland is provided.
The implementation status notes vkCreateSwapchainKHR, vkQueuePresentKHR, vkCreateWaylandSurfaceKHR, as well as checks for Wayland presentation support. The presence of swapchain and Wayland surface indicates that the driver is aimed not only at offline testing but also at outputting images to a real windowing environment in Linux.Part of the WSI for X11 and Windows is still in progress.
vkCreateXcbSurfaceKHR, vkCreateXlibSurfaceKHR, vkCreateWin32SurfaceKHR and the corresponding presentation support checking functions are marked as WIP. Wayland is already present, while X11/Windows support is not yet fully developed.Some elements of Vulkan 1.0 are still not ready or supported.
The WIP status includes, for example, vkCreatePipelineCache, vkCreateSemaphore, vkGetQueryPoolResults, vkMergePipelineCaches, part of the dynamic states, and timestamp commands. Sparse functions like vkQueueBindSparse and vkGetImageSparseMemoryRequirements are marked as unsupported. Ape is close to Vulkan 1.0 in coverage but is not yet a universal replacement for a standard Vulkan driver.Recent improvements in rendering and synchronization have emerged.
Changes in the project history from June 5–6 include the addition of primitive restart, integer texture sampling, mip/lod management during sampling, and the implementation of binary semaphores. The project is actively evolving towards practical compatibility with Vulkan tests and real graphic scenarios.The project does not aim for performance.
The author clearly states that Ape is created for studying Vulkan and does not aim to be a performant or production-ready driver. Ape should be regarded as a research project, a teaching implementation of Vulkan, and an experiment with Zig, rather than a competitor to Mesa RADV, ANV, NVK, or Lavapipe.
In summary, Ape is interesting not because it can replace Mesa tomorrow, but because it is a standalone implementation of Vulkan ICD in Zig with its own SPIR-V interpreter, software renderer, and already significant coverage of Vulkan 1.0. While it offers little benefit to regular users for now, it appears to be an intriguing live testbed for driver developers, runtime authors, and those studying the inner workings of Vulkan.
Source: linux.org.ru
