Ape — en ny öppen programvaruimplementation av Vulkan ICD

Presenteras ny experimentell Vulkan-drivrutin Ape — en öppen programvaruimplementation av Vulkan ICD, nästan helt skriven på Zig och använder inte Mesa-kod. Projektet strävar ännu inte efter industriell tillämpning: författaren beskriver det som ett lärande försök att "bygga en drivrutin för hand" och varnar för att använda Ape i seriösa projekt. Koden publiceras under en licens MIT.

Intresset för Ape växte efter att i specifikationen Vulkan fick en separat vendor-ID för Ape och driver-ID för ApeSoft. Den relevanta pull requesten i KhronosGroup/Vulkan-Docs-arkivet har blivit sammanslagen 6 juni 2026. I kommentaren angav författaren att de arbetar med en amatör Vulkan-drivrutin och närmar sig att klara alla tester för Vulkan 1.0.

Egentligen är Ape inte en drivrutin för ett specifikt grafikkort, utan en programvarubaserad Vulkan-renderare, nära besläktad med Mesa Lavapipe: Vulkan-kommandon utförs av den egna implementationen, utan att vända sig till den hårdvarubaserade GPU-drivrutinen. Samtidigt är Ape inte baserad på Mesa och är skriven som en självständig kodbas i Zig.

Vad Ape redan kan

• Fungerar som Vulkan ICD.
  Ape är utformad som Installable Client Driver — alltså som en drivrutin som kan fångas upp av den standard Vulkan loadern genom ICD-manifestet. Efter kompilering föreslår författaren att ange Vulkan-loadern till den relevanta manifestfilen. Detta gör projektet till mer än bara en samling experiment, utan en verklig implementation av en Vulkan-drivrutin, även om det är ett utbildningsprojekt. Vulkan-loadern är just avsedd för att upptäckta och ansluta flera ICD-drivrutiner i systemet.

• Helt skriven i Zig.
  Den huvudsakliga kodbasen för Ape är skriven i Zig; på huvudforge-sidan för projektet anges språket som Zig 99,9%. Phoronix betonar särskilt att projektet inte beror på Mesa och är implementerat just i Zig, istället för C/C++. Grafiska drivrutiner skrivs traditionellt i C/C++, och Ape visar att Vulkan ICD kan implementeras även på ett modernare systemprogrammeringsspråk.

• Det finns en programvaruimplementation av ApeSoft.
  I projektet har en programvaruimplementation uteslutits Mjuk, som ligger inom själva kodbasen för drivrutinen. Den använder sin egen SPIR-V-tolkar och sin egen renderare. Ape tar inte bara emot Vulkan-anrop, utan försöker också självständigt utföra shaders och rendering på CPU:n.

• Stöd för byggnation genom Zig build.
  För den programvaruimplementering som anges i README används kommandot zig build soft för att bygga. Därefter måste Vulkan-laddaren konfigureras med ICD-manifestet. Detta är fortfarande tydligt ett verktyg för utvecklare och entusiaster, snarare än ett paket för «installera och köra».

• En betydande del av Vulkan 1.0 har implementerats.
  I README finns en lista över statusen för Vulkan 1.0-funktioner. Bland de implementerade finns skapande av instans och enhet, minnesallokering, buffertar, bilder, kommandobuffertar, renderpass, framebuffer, grafikpipeline, beräkningspipeline, shadermoduler, deskriptorsatser, swapchain och grundläggande renderingskommandon. Genom uppsättningen av implementerade funktioner har projektet redan gått längre än «hello triangle»-experimentet, men för att uppnå status som en fullständig kompatibel drivrutin behöver det fortfarande genomgå tester och avsluta utestående delar.

• Det finns renderings- och beräkningskommandon.
  I listan över implementerade funktioner noteras vkCmdDraw, vkCmdDrawIndexed, vkCmdDrawIndirect, vkCmdDrawIndexedIndirect, vkCmdDispatch och vkCmdDispatchIndirect. Ape täcker inte bara den grundläggande infrastrukturen för Vulkan, utan även två viktiga API-scenario: grafisk rendering och beräkningspipelines.

• Swapchain och utdata via Wayland stöds.
  I implementationsstatusen noteras vkCreateSwapchainKHR, vkQueuePresentKHR, vkCreateWaylandSurfaceKHR, samt kontroller för stöd för Wayland-presentation. Närvaron av swapchain och Wayland-yta innebär att drivrutinen är inriktad på inte bara offline-tester, utan också på att producera grafik i en verklig fönsterhanteringsmiljö i Linux.

• Delen WSI för X11 och Windows är fortfarande under arbete.
  vkCreateXcbSurfaceKHR, vkCreateXlibSurfaceKHR, vkCreateWin32SurfaceKHR och motsvarande funktioner för kontroller av presentationsstöd är markerade som WIP. Wayland är redan närvarande, medan X11/Windows-stödet ännu inte är helt färdigt.

• Vissa delar av Vulkan 1.0 är fortfarande inte klara eller stöds inte.
  I WIP-statusen nämns till exempel vkCreatePipelineCache, vkCreateSemaphore, vkGetQueryPoolResults, vkMergePipelineCaches, vissa dynamiska tillstånd och timestamp-kommandon. Sparse-funktioner som vkQueueBindSparse och vkGetImageSparseMemoryRequirements har markerats som unsupported. Ape närmar sig Vulkan 1.0 i omfattning, men är fortfarande inte en universell ersättning för en riktig Vulkan-drivrutin.

• Det har kommit nya uppdateringar för rendering och synkronisering.
  I projektets historia den 5–6 juni noterades förändringar som tillägg av primitive restart, integer texture sampling, hantering av mip/lod vid sampling och implementering av binära semaforer. Projektet utvecklas aktivt mot praktisk kompatibilitet med Vulkan-tester och verkliga grafiska scenarier.

• Projektet syftar inte till prestanda.
  Författaren påstår direkt att Ape är skapat för att studera Vulkan och strävar inte efter att vara en produktionsklar eller högpresterande drivrutin. Ape bör uppfattas som ett forskningsprojekt, en utbildningsimplementering av Vulkan och ett experiment med Zig, snarare än en konkurrent till Mesa RADV, ANV, NVK eller Lavapipe.

Sammanfattningsvis är Ape intressant inte för att man kan ersätta Mesa med den imorgon, utan för att det är en självständig implementering av Vulkan ICD på Zig med en egen SPIR-V-tolkare, programvarurenare och redan märkbart stöd för Vulkan 1.0. För vanliga användare finns det fortfarande lite nytta, men för drivrutinsutvecklare, skapare av miljöer och människor som studerar Vulkan inre funktioner ser projektet ut som en fascinerande levande experimentanläggning.

Källa: linux.org.ru