Ape — новая открытая программная реализация Vulkan ICD

Представлен новый экспериментальный Vulkan-драйвер Ape — открытая программная реализация Vulkan ICD, написанная почти целиком на Zig и не использующая код Mesa. Проект пока не претендует на промышленное применение: автор прямо описывает его как учебную попытку «собрать драйвер руками» и предупреждает не использовать Ape в серьёзных проектах. Код опубликован под лицензией MIT.
Интерес к Ape появился после того, как в спецификацию Vulkan был добавлен отдельный vendor ID для Ape и driver ID для ApeSoft. Соответствующий pull request в репозитории KhronosGroup/Vulkan-Docs был смержен 6 июня 2026 года. В комментарии автор указал, что работает над любительским Vulkan-драйвером и приближается к прохождению всех тестов Vulkan 1.0.
По сути, Ape — это не драйвер для конкретной видеокарты, а программный Vulkan-рендерер, близкий по назначению к Mesa Lavapipe: Vulkan-команды выполняются силами собственной реализации, без обращения к аппаратному GPU-драйверу. При этом Ape не основан на Mesa и написан как самостоятельная кодовая база на Zig.
Что уже умеет Ape
-
Работает как Vulkan ICD. Ape оформлен как Installable Client Driver — то есть как драйвер, который может подхватываться стандартным Vulkan loader через ICD-манифест. После сборки автор предлагает указать загрузчику Vulkan на соответствующий manifest-файл. Это делает проект не просто набором экспериментов, а настоящей реализацией Vulkan-драйвера, пусть и учебной. Vulkan loader как раз рассчитан на обнаружение и подключение нескольких ICD-драйверов в системе.
-
Полностью написан на Zig. Основная кодовая база Ape написана на Zig; на основной forge-странице проекта язык указан как Zig 99,9%. Phoronix отдельно подчёркивает, что проект не зависит от Mesa и реализован именно на Zig, а не на C/C++. Графические драйверы традиционно пишутся на C/C++, а Ape показывает, что Vulkan ICD можно реализовывать и на более современном системном языке.
-
Есть программная реализация ApeSoft. В проекте выделена программная реализация Soft, которая находится внутри самой кодовой базы драйвера. Она использует собственный SPIR-V-интерпретатор и собственный рендерер. Ape не просто принимает Vulkan-вызовы, а пытается самостоятельно выполнять шейдеры и рендеринг на CPU.
-
Поддерживается сборка через Zig build. Для программной реализации в README указан способ сборки командой
zig build soft. После этого нужно настроить Vulkan loader на ICD manifest. Пока это явно инструмент для разработчиков и энтузиастов, а не пакет «установил и запустил». -
Реализована значительная часть Vulkan 1.0. В README приведён список статуса функций Vulkan 1.0. Среди реализованных — создание экземпляра и устройства, выделение памяти, буферы, изображения, command buffers, render pass, framebuffer, graphics pipeline, compute pipeline, shader modules, descriptor sets, swapchain и базовые команды отрисовки. По набору реализованных функций проект уже ушёл дальше «hello triangle»-эксперимента, но до статуса полноценного совместимого драйвера ему ещё нужно пройти проверку и закрыть незавершённые места.
-
Есть команды отрисовки и compute. В списке реализованных функций отмечены
vkCmdDraw,vkCmdDrawIndexed,vkCmdDrawIndirect,vkCmdDrawIndexedIndirect,vkCmdDispatchиvkCmdDispatchIndirect. Ape покрывает не только базовую инфраструктуру Vulkan, но и два ключевых сценария API: графическую отрисовку и вычислительные пайплайны. -
Поддерживаются swapchain и вывод через Wayland. В статусе реализации отмечены
vkCreateSwapchainKHR,vkQueuePresentKHR,vkCreateWaylandSurfaceKHR, а также проверки поддержки Wayland presentation. Наличие swapchain и Wayland-поверхности означает, что драйвер нацелен не только на офлайн-тесты, но и на вывод изображения в реальную оконную среду Linux. -
Часть WSI для X11 и Windows пока в работе.
vkCreateXcbSurfaceKHR,vkCreateXlibSurfaceKHR,vkCreateWin32SurfaceKHRи соответствующие функции проверки presentation support помечены как WIP. Wayland уже присутствует, а X11/Windows-поддержка ещё не доведена до готового состояния. -
Некоторые элементы Vulkan 1.0 пока не готовы или не поддерживаются. В статусе WIP указаны, например,
vkCreatePipelineCache,vkCreateSemaphore,vkGetQueryPoolResults,vkMergePipelineCaches, часть динамических состояний и timestamp-команды. Sparse-функции вродеvkQueueBindSparseиvkGetImageSparseMemoryRequirementsпомечены как unsupported. Ape близок к Vulkan 1.0 по охвату, но ещё не является универсальной заменой нормального Vulkan-драйвера. -
Появились свежие доработки рендеринга и синхронизации. В истории проекта 5–6 июня отмечены изменения вроде добавления primitive restart, integer texture sampling, управления mip/lod при выборке и реализации binary semaphores. Проект активно развивается именно в сторону практической совместимости с тестами Vulkan и реальными графическими сценариями.
-
Проект не ставит целью производительность. Автор прямо пишет, что Ape создан для изучения Vulkan и не стремится быть производительным или production-ready драйвером. Воспринимать Ape стоит как исследовательский проект, учебную реализацию Vulkan и эксперимент с Zig, а не как конкурент Mesa RADV, ANV, NVK или Lavapipe.
В сухом остатке Ape интересен не тем, что его можно будет завтра поставить вместо Mesa, а тем, что это самостоятельная реализация Vulkan ICD на Zig с собственным SPIR-V-интерпретатором, программным рендерером и уже заметным покрытием Vulkan 1.0. Для обычных пользователей пользы пока мало, зато для разработчиков драйверов, авторов рантаймов и людей, изучающих внутреннее устройство Vulkan, проект выглядит как любопытный живой полигон.
>>> Источник
