LINUX.ORG.RU

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

 ape,


0

3

Представлен новый экспериментальный 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, проект выглядит как любопытный живой полигон.

>>> Источник

★★★★★

Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 1)

Полностью написан на Zig.

Килер-фича, я так понимаю.

Поддерживается сборка через Zig build.

Ваще килер.

Реализована значительная часть Vulkan 1.0.

Но не весь, я так понимаю.

Часть WSI для X11 и Windows пока в работе.

Некоторые элементы Vulkan 1.0 пока не готовы или не поддерживаются.

Предлагаю переименовать новость в «на zig появился очередной недо-проект». На вопросы «а что такое zig» отвечать в каментах.

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 2)
Ответ на: комментарий от dimgel

ну сам похороникс решил подсветить проектик, чем ЛОР хуже, а так да

unclestephen ★★★★★
() автор топика
Ответ на: комментарий от dimgel

очередной недо-проект

Почти полноценный вулкан-рендер с нуля - это такой "недопроект", что ему многие перепроекты могут позавидовать.

Полностью написан на Zig.

Килер-фича, я так понимаю.

И тут ирония напрасна - там рантайм API целиком сишный и его прилично. Это вполне себе история успеха и для конкретно этого проекта и для зига в целом.

r--r--r--
()
Ответ на: комментарий от r--r--r--

И тут ирония напрасна - там рантайм API целиком сишный и его прилично. Это вполне себе история успеха и для конкретно этого проекта и для зига в целом.

Это ж сколько его придется переписывать на раст…

LightDiver ★★★★★
()
Ответ на: комментарий от dimgel

у меня есть сторонняя реализация wsi для x11 (но тоже очень WIP), можно попробовать прикрутить.
Но zig - очередной подсос llvm (или уже нет?), потому возиться не слишком хочется

mittorn ★★★★★
()
Последнее исправление: mittorn (всего исправлений: 1)
Ответ на: комментарий от mittorn

Но zig - очередной подсос llvm

В дебаг-сборках вроде нет. Но любим мы его не за это. Любим его, что он amazing, с удивительным бесшовным интеропом с C/C++, с одним и тем же синтаксисом runtime и compile-time; и главное, что бинари получаются крохотные и без никаких зависимостей.

sarumeister
()
Ответ на: комментарий от sarumeister

Тогда звучит уже интереснее. Меня сильно напрягает завязывание экосистем на llvm, например не осталось ни одного opencl компилятора, не использующего llvm-libclc

mittorn ★★★★★
()

приближается к прохождению всех тестов Vulkan 1.0

Велика ли разница до последней версии? Вообще, проект крутой, думаю когда кто то будет делать свою видеокарту, им это пригодится просто очень

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от BydymTydym

Компилировать мы не бросим
Ноль-точка-шесть-восемь!

DzenPython
()
Ответ на: комментарий от AlexM

Даже на libc нет зависимостей?

Ну вот делаешь ты программу для EFI. Или программу для WASM. Зачем туда тащить libc? Не надо это.

saru@rockpi:~/p/my-shrink-path$ zig build -Doptimize=ReleaseSmall
saru@rockpi:~/p/my-shrink-path$ ls -al zig-out/bin/my-shrink-path
-rwxr-xr-x 1 saru saru 12472 Jun  9 05:50 zig-out/bin/my-shrink-path
saru@rockpi:~/p/my-shrink-path$ ldd zig-out/bin/my-shrink-path
        not a dynamic executable

На тех выходных сделал крон-подобную напоминалку под виндовз, получилось 145КБ. Стал разбираться, оказалось 126КБ отъела главная иконка в ресурсах.

sarumeister
()
Ответ на: комментарий от sarumeister

Я знаю, зачем нужны полностью статические программы. Но в наше непростое время добиться полной статики на Линуксе сложновато, с учётом того, что glibc-шный NSS предполагает динамику, а , например, с musl-ом не всякую программу скомпилируешь.

Если у zig-а получается - хорошо.

AlexM ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.