A Vulkan API sorra kap kisebb frissítéseket, amelyekbe jellemzően olyan kiterjesztések kerülnek bele, amiket nem kötelező támogatni. Később azonban a Khronos Group a fontosabbnak ítélt fejlesztéseket beveszi egy új Vulkan verzióba, így kényszerítve a gyártókat arra, hogy az implementációikban javítsák a minimum szinten elérhető lehetőségeket.
Hirdetés
A Vulkan ezúttal a Vulkan Roadmap 2026 mérföldkővel bővül, amely a Vulkan 1.4-hez és a Vulkan Roadmap 2024-hez képest további kiterjesztéseket emelne be PC-n a Core specifikáción túli funkcionalitásba. Ez papíron nem kötelező érvényű, de a fő cél az, hogy iparági szinten legyen egy egységes alap PC-n, így a fejlesztők tovább tudnak menni a Core specifikáció limitjein. A Vulkan Roadmap 2026 az alábbi kiterjesztéseket javasolja:
- VK_KHR_robustness2
- VK_KHR_pipeline_binary
- VK_KHR_fragment_shading_rate
- VK_KHR_shader_clock
- VK_KHR_workgroup_memory_explicit_layout
- VK_KHR_compute_shader_derivatives
- VK_KHR_maintenance7
- VK_KHR_maintenance8
- VK_KHR_maintenance9
- VK_KHR_depth_clamp_zero_one
- VK_KHR_copy_memory_indirect
- VK_KHR_shader_untyped_pointers
- VK_KHR_surface
- VK_KHR_swapchain
- VK_KHR_present_mode_fifo_latest_ready
- VK_KHR_present_id2
- VK_KHR_present_wait2
- VK_KHR_surface_maintenance1
- VK_KHR_swapchain_maintenance1
- VK_KHR_cooperative_matrix
Tekintve azt, hogy a mai modern VGA-k grafikus meghajtói ezeket majdnem mind támogatják már, különösebb háttérmunka nem szükséges, a fejlesztők számára pedig egyszerűsödik az egységes alap kezelése. A fentieken túl módosulnak a pufferekre vonatkozó limitek is, amelyet az alábbi táblázat részletez:
| Funkciólimit (minimum) |
Core 1.0 | Roadmap 2026 |
|---|---|---|
| maxPerStageDescriptorUniformBuffers | 15 | 200 |
| maxPerStageDescriptorStorageBuffers | 4 | 200 |
| maxPerStageDescriptorInputAttachments | 4 | 8 |
| maxDescriptorSetStorageBuffers | 96 | 1800 |
| maxDescriptorSetUniformBuffers | 96 | 1800 |
| maxDescriptorSetInputAttachments | 4 | 8 |
| maxVertexOutputComponents | 64 | 124 |
| maxTessellationControlPerVertexInputComponents | 64 | 128 |
| maxTessellationControlPerVertexOutputComponents | 64 | 128 |
| maxTessellationControlTotalOutputComponents | 2048 | 4096 |
| maxTessellationEvaluationInputComponents | 64 | 128 |
| maxTessellationEvaluationOutputComponents | 64 | 128 |
| maxGeometryOutputComponents | 64 | 128 |
| maxFragmentInputComponents | 64 | 112 |
| maxFragmentOutputAttachments | 4 | 8 |
| maxComputeSharedMemorySize | 16384 | 32768 |
| subPixelPrecisionBits | 4 | 8 |
| maxViewportDimensions.width | 7680 | 8192 |
| maxViewportDimensions.height | 7680 | 8192 |
| maxFramebufferWidth | 7680 | 8192 |
| maxFramebufferHeight | 7680 | 8192 |
A Khronos Group azt várja, hogy a Vulkan Roadmap 2026 mérföldkövet támogatni fogják a modern rendszerek, és ebben valószínűleg nem tévednek, a változások között ugyanis nincs olyan követelmény, amivel a ma kapható VGA-k ne birkóznának meg.
A fentieknél sokkal lényegesebb újítás lesz viszont a VK_EXT_descriptor_heap kiterjesztés bevezetése, amely nagymértékben módosítja a Vulkan API jelenlegi leírórendszerét. Ez már része a Vulkan 1.4.340-es kiadásnak, de még nem kötelező támogatni.
Az új specifikáció az eddigi legnagyobb változás a Vulkan API történetében, és azért van rá szükség, mert az eredet leírórendszert anno úgy tervezték, hogy a lehető legtöbb hardver tudja támogatni. Ez tíz éve teljesen átgondoltnak számított, hiszen amikor az API megjelent, akkor az volt a hasznos, ha sok cég tud valamilyen implementációt tervezni rá. A széleskörű hardveres támogatásért cserébe ugyanakkor kompromisszumokat kellett kötni. Ez a legtöbb esetben nem jelentett nagy gondot, de ahogy terjedt a Vulkan API, úgy szélesedtek a felhasználási módjai, és ezzel az eredeti leírórendszer limitációi is elkezdtek a felszínre törni.
Az egyik legnagyobb problémának a VKD3D-Proton és az NVIDIA párosítása számított. Mint ismeretes az előbbi felület a DirectX 12 címek futtatását oldja meg Vulkan API-n keresztül, viszont a két grafikus API leírórendszere valamelyest eltér, és ehhez még hozzájönnek a hardveres különbségek is gyártói oldalról. Ez végeredményben azt eredményezte, hogy ha a programfuttatás nem natívan történik, hanem a VKD3D-Proton kompatibilitási rétegen keresztül, akkor a nagyon specifikus, natív implementációval is eleve nehezen kezelhető eltérések esetenként nagyon nem fognak optimálisan működni.
A gyakorlatban azt látjuk, hogy a VKD3D-Proton elég jól dolgozik az AMD és az Intel grafikus vezérlőinek alapvető hátterével, de bizonyos körülmények között gondjai vannak az NVIDIA oldalán, amit elsődlegesen az idéz elő, hogy a VKD3D-Proton a DirectX 12 memóriablokkokat egyetlen nagy leírókészletként emulálja, amit a Vulkan API ugyan jól kezel, de az így generált leírókészletek fizikailag túl nagyok ahhoz, hogy beleférjenek egyetlen uniform pufferbe, ami sokat lassít az NVIDIA GPU-inak teljesítményén. Mivel ez egy hardveres tényező, az NVIDIA zárt meghajtója mellett a nyílt NVK is ugyanilyen problémába fut bele, azaz a grafikus architektúra alapvető áttervezése nélkül megoldhatatlan lenne.
A fentiek miatt merült fel az a tényező korábban, hogy a Vulkan API eredeti leírórendszere legyen módosítva, hogy sokkal jobban illeszkedjen a DirectX 12 modelljéhez, illetve a shader modell 6.6-ban bevezetett változásokhoz is. Az új kiterjesztés lehetővé teszi a VKD3D-Proton számára azt, hogy ne kelljen egyetlen nagy leírókészletként emulálni a DirectX 12 memóriablokkokat, ezáltal megszűnik az a specifikus gond, ami az NVIDIA GPU-kat sújtja ebből a szempontból. Ráadásul mindez a többi gyártót abszolút nem érinti, mert az AMD és az Intel grafikus architektúráinak hardveres működése a bekötési modell szempontjából jóval rugalmasabb, így tökéletesen alkalmas az új kiterjesztéshez is.
A VK_EXT_descriptor_heap ugyanakkor még nem kötelezően támogatandó kiterjesztés, tehát a gyártók döntenek róla, hogy beépítik-e az implementációikba. Hosszabb távon valószínűleg át lesz emelve a Core specifikációba, így esélyes, hogy a várhatóan két év múlva esedékes Vulkan Roadmap mérföldkőnek már a része lesz.
