Még február közepén számoltunk be arról, hogy ténylegesen elkészült a Vulkan API, ugyanakkor már akkor lehetett tudni, hogy a gyártók kihasználnák, hogy számos specifikus kiterjesztést tervezhetnek a rendszerhez. Bár az OpenGL kapcsán sokak számára ezek csak kellemetlenséget okoztak, a Vulkan ebből a szempontból más lesz, ugyanis a Khronos Group nagyon megszigorította a kiterjesztések elfogadására vonatkozó szabályzatot. Többek között mostantól abszolút követelmény, hogy egy kiterjesztésnek egyetlen pontja sem mehet szembe a Vulkan API core specifikációjával, vagyis tulajdonképpen nem lehet olyan kiterjesztést kiadni, amely valamely ponton megváltoztatja a rendszer alapvető követelményeit.
A fentiek miatt van az, hogy bár a Vulkan már kapott némi gyártói szeretetet, példaként említve a VK_NV_glsl_shader kiterjesztést, de ez megszegi az API alapvető követelményét, vagyis nem csak a SPIR-V-t fogadja el shader nyelvként, emiatt a Khronos Group ezt nem építi be, mivel az ellentmondást jelentene core specifikációban leírtakkal. A konzorcium szerint az OpenGL-ben tipikusan a gyártói kiterjesztések, hanem az ezekkel érkező olyan ellentmondások jelentették a gondot, amelyek bizonyos core specifikációkat lecseréltek a működés biztosítása érdekében. Ezt a Vulkan API-ban már nem lehet megtenni.
A fentiek miatt kellett hónapokat várni, hogy végül megérkezzen az első, hivatalosan is elfogadott gyártói kiterjesztésre, amely már ténylegesen ott van a legújabb Vulkan verzióban. Ezt az AMD szolgáltatta VK_AMD_rasterization_order néven. Ez a kiterjesztés ráadásul nagyon hasznos, ugyanis lehetővé teszi a fejlesztők számára az úgynevezett sorrendtől független raszterizálást. Ezt valójában egyetlen API sem engedélyezi önmagában, mivel a grafika számítások alapja az, hogy ezek a beérkezésük sorrendjében adjanak eredményeket. Utóbbi egyfajta garancia arra, hogy a raszterizálás végeredménye megfelelő minőségű lesz minden esetben. Vannak olyan feladatok, ahol viszont abszolút lényegtelen a sorrend, mint például a blending nélküli G-puffer kreálás. Ilyenkor a legtöbb meghajtó eleve beállít egy speciális raszterizálási módot, hogy a hardver ne törődjön a sorrenddel, tehát ez a probléma látszólag meg van oldva.
Valójában azonban vannak olyan helyzetek is, amikor tulajdonképpen előnyös lenne a sorrendtől független raszterizálásra vonatkozó mód, de a meghajtó nem képes aktiválni, mert a kód előzetes elemzése alapján ezt nem ítéli biztonságosnak. A fejlesztők azonban sokkal jobban ismerik a saját leképezőjüket, amelyet ráeresztenek a hardverekre, és például találhatnak olyan szituációkat, amelyekre a meghajtó nem tudja aktiválni a speciális raszterizálási módokat, ugyanakkor érdemes sorrendtől független raszterizálást alkalmazni, mert az eredményen nem változtat, viszont gyorsít a feldolgozáson. Az AMD kiterjesztése gyakorlatilag ezt a manuális kontrollt teszi lehetővé.
A Vulkan új kiterjesztési rendszerében még az is jó hír, hogy a core specifikációk kötelező betartása miatt az AMD kiterjesztését gyakorlatilag bármikor támogathatja a többi gyártó is, ha az adott architektúra képes a szükséges raszterizációs módot alkalmazni. A legtöbb modernebb GPU-architektúra szerencsére ilyen, mivel ez a trükk azért nem számít újdonságnak a hardvereken belül, csak manuális formában eddig nem volt kontrollálható. Tehát a gyártók számára csak a Vulkan meghajtót kell frissíteni az új kiterjesztés használatához, és lényegében az egész kvázi hamar szabványos szintre emelhető, így mindenki képes profitálni az újítás adta teljesítményelőnyből.
Egyelőre persze a támogatás csak a GCN architektúrára épülő Radeonokon lehetséges a legfrissebb, 16.5.2-es családba tartozó Radeon Software meghajtóval, de ez nagyrészt annak köszönhető, hogy a többi gyártónak még nem volt ideje a kiterjesztést megvizsgálni.
