Przedstawiony nowy eksperymentalny sterownik Vulkan Ape — otwarta implementacja programu Vulkan ICD, napisana niemal w całości w Zig i nie korzystająca z kodu Mesa. Projekt na razie nie jest przeznaczony do użytku przemysłowego: autor wyraźnie opisuje go jako próbę edukacyjną „zbudowania sterownika ręcznie” i ostrzega, aby nie używać Ape w poważnych projektach. Kod opublikowany jest na licencji MIT.
Zainteresowanie Ape pojawiło się po tym, jak do specyfikacji Vulkan dodano oddzielny identyfikator dostawcy dla Ape i identyfikator sterownika dla ApeSoft. Odpowiedni pull request w repozytorium KhronosGroup/Vulkan-Docs został połączony 6 czerwca 2026 roku. W komentarzu autor wskazał, że pracuje nad amatorskim sterownikiem Vulkan i zbliża się do ukończenia wszystkich testów Vulkan 1.0.
W zasadzie Ape — to nie jest sterownik dla konkretnej karty graficznej, a programowy renderer Vulkan, podobny do Mesa Lavapipe: polecenia Vulkan są wykonywane przy użyciu własnej implementacji, bez odwołania do sprzętowego sterownika GPU. Przy tym Ape nie jest oparty na Mesa i napisany jako niezależna baza kodowa w Zig.
Co już potrafi Ape
Działa jako Vulkan ICD.
Ape jest zdefiniowany jako Installable Client Driver — to znaczy jako sterownik, który może być przechwytywany przez standardowy loader Vulkan przez manifest ICD. Po zbudowaniu autor sugeruje wskazanie loaderowi Vulkan odpowiedniego pliku manifestu. To sprawia, że projekt nie jest tylko zbiorem eksperymentów, a prawdziwą implementacją sterownika Vulkan, chociaż edukacyjną. Loader Vulkan jest specjalnie zaprojektowany do wykrywania i łączenia kilku sterowników ICD w systemie.Całkowicie napisany w Zig.
Główna baza kodowa Ape napisana jest w Zig; na głównej stronie projektu język wskazany jest jako Zig 99,9%. Phoronix podkreśla, że projekt nie zależy od Mesa i jest zrealizowany właśnie w Zig, a nie w C/C++. Graficzne sterowniki tradycyjnie pisane są w C/C++, a Ape pokazuje, że Vulkan ICD można implementować również w nowocześniejszym języku systemowym.Istnieje programowa implementacja ApeSoft.
W projekcie выделена programowa implementacja Miękki, która znajduje się wewnątrz samej bazy kodowej sterownika. Używa własnego interpretatora SPIR-V i własnego renderera. Ape nie tylko przyjmuje wywołania Vulkan, ale stara się samodzielnie wykonywać shadery i renderowanie na CPU.Obsługuje budowę przez Zig build.
Aby zrealizować implementację, w pliku README podano sposób budowania za pomocą polecenia zig build soft. Następnie należy skonfigurować loader Vulkan na manifest ICD. Jak na razie jest to wyraźnie narzędzie dla programistów i entuzjastów, a nie pakiet "zainstaluj i uruchom".Zrealizowano znaczną część Vulkan 1.0.
W README znajduje się lista statusu funkcji Vulkan 1.0. Wśród zrealizowanych funkcji są: tworzenie instancji i urządzenia, alokacja pamięci, bufory, obrazy, buforów poleceń, render pass, framebuffer, pipeline graficzny, pipeline obliczeniowy, moduły shaderów, zestawy deskryptorów, swapchain i podstawowe polecenia rysowania. Dzięki zrealizowanym funkcjom projekt przeszedł już do przodu od eksperymentu "hello triangle", ale aby osiągnąć status w pełni zgodnego sterownika, musi jeszcze przejść weryfikację i zamknąć niedokończone miejsca.Obsługiwane są polecenia rysowania oraz obliczeniowe.
Na liście zrealizowanych funkcji znajdują się vkCmdDraw, vkCmdDrawIndexed, vkCmdDrawIndirect, vkCmdDrawIndexedIndirect, vkCmdDispatch i vkCmdDispatchIndirect. Ape obejmuje nie tylko podstawową infrastrukturę Vulkan, ale także dwa kluczowe scenariusze API: rysowanie grafiki i obliczeniowe pipeline'y.Obsługiwane są swapchain oraz wyjście przez Wayland.
W statusie realizacji wymienione są vkCreateSwapchainKHR, vkQueuePresentKHR, vkCreateWaylandSurfaceKHR oraz kontrole wsparcia dla prezentacji Wayland. Obecność swapchain i powierzchni Wayland oznacza, że sterownik jest nastawiony nie tylko na testy offline, ale także na wyświetlanie obrazu w rzeczywistym środowisku okienkowym w systemie Linux.Część WSI dla X11 i Windows jest w trakcie pracy.
vkCreateXcbSurfaceKHR, vkCreateXlibSurfaceKHR, vkCreateWin32SurfaceKHR oraz odpowiednie funkcje kontrole wsparcia dla prezentacji oznaczone są jako WIP. Wayland jest już dostępny, a wsparcie dla X11/Windows jeszcze nie zostało doprowadzone do stanu gotowości.Niektóre elementy Vulkan 1.0 nie są jeszcze gotowe lub nie są obsługiwane.
W statusie WIP wymienione są na przykład vkCreatePipelineCache, vkCreateSemaphore, vkGetQueryPoolResults, vkMergePipelineCaches, część dynamicznych stanów i polecenia timestamp. Sparse-funkcje takie jak vkQueueBindSparse i vkGetImageSparseMemoryRequirements są oznaczone jako unsupported. Ape jest bliskie Vulkan 1.0 pod względem zakresu, ale nadal nie stanowi uniwersalnej alternatywy dla normalnego sterownika Vulkan.Pojawiły się nowe ulepszenia renderowania i synchronizacji.
W historii projektu z 5-6 czerwca odnotowano zmiany, takie jak dodanie restartu prymitywów, próbkowanie tekstur całkowitych, zarządzanie mip/lod podczas próbkowania oraz wdrożenie binarnych semaforów. Projekt aktywnie rozwija się w kierunku praktycznej zgodności z testami Vulkan i rzeczywistymi scenariuszami graficznymi.Projekt nie ma na celu osiągnięcia wysokiej wydajności.
Autor wyraźnie pisze, że Ape został stworzony do nauki Vulkan i nie ma na celu bycia wydajnym lub gotowym do produkcji sterownikiem. Należy postrzegać Ape jako projekt badawczy, edukacyjną implementację Vulkan oraz eksperyment z Zig, a nie jako konkurenta Mesa RADV, ANV, NVK czy Lavapipa.
W ostatecznym rozrachunku Ape interesuje nie tym, że można go jutro zainstalować zamiast Mesa, ale tym, że jest samodzielną implementacją Vulkan ICD w Zig z własnym interpretatorem SPIR-V, programowym renderem i już zauważalnym wsparciem dla Vulkan 1.0. Dla zwykłych użytkowników korzyści są na razie niewielkie, ale dla twórców sterowników, autorów środowisk uruchomieniowych i osób badających wewnętrzną strukturę Vulkan projekt ten wydaje się ciekawym, żywym polem eksperymentalnym.
Źródło: linux.org.ru
