Az AMD még a nyár első hónapjában állt elő a Vulkan Memory Allocator (VMA) függvénykönyvtárral, amely kifejezetten azokat a fejlesztőket célozta, akiknek az új explicit API alacsonyabb szintű elérése inkább teher, mint előny. A Vulkan API-ra írt alkalmazásnál ugyanis mindent előre meg kell mondani, ezáltal lekezelni az egyes olyan szituációkat, amelyeket a korábbi API-knál kezelt a meghajtó. Tipikusan a memóriaallokáció és az erőforrások kreálása hathat bonyolultnak a Direct3D 11 és OpenGL API-khoz viszonyítva. Ennek az oka, hogy az egész alkalmazás működéséhez rengeteg olyan kódot kell a programba írni, amelyek önmagukban nem csinálnak semmit, csak a programozó munkáját segítik a különböző automatizálásokkal, végeredményben viszont ez biztosítja a teljesítményt.
A fenti nehézségre dolgozta ki az AMD az alábbi GitHUB oldalon elérhető VMA-t, amit egyszerű integrálni bármilyen Vulkan API-ra írt programba, kompatibilis akármelyik gyártó Vulkan implementációjával, és tulajdonképpen jelentősen egyszerűsíti a fejlesztők munkáját azáltal, hogy előre megírt funkciókat kapnak, amelyeket szimplán csak meg kell hívni. A friss hírek szerint hasonló koncepción már dolgozik a Microsoft is a DirectX 12-re vonatkozóan, tehát nem egyedi ez az irány.
A friss bejelentés annyi, hogy elkészült a 2.0-s változat alfa verziója, amely pár dolgon változtat, így az 1.0-s verzióval való kompatibilitást is megtöri, továbbá pár új függvényt és struktúrát, illetve számos ezekre épülő újítást kínál.
A legfontosabb extra talán az úgynevezett lost allocations támogatása. Mint ismeretes az explicit API-k esetében a memória vezérlése teljes egészében az alkalmazás feladata, így az egyes erőforrások nem kerülnek automatikusan a rendszermemóriába. Ezáltal például a Vulkan API esetében nagyon vigyázni kell arra, hogy sose kreáljon a program egy olyan allokációt, amely esetleg már nem fér bele a videomemóriába, ugyanis ha ez megtörténik, akkor az allokáció elveszik. Az ilyen helyzetekre a validátor felhívja a figyelmet, így az egyes programok a kiadásra már jól vannak megtervezve ebből a szempontból is, de nyilván a fejlesztés aktív szakaszában ez a tényező sok programösszeomlást eredményez. Ráadásul nagyon tipikus a mai videojáték-motorok esetében, hogy jóval több adattal dolgoznak, mint amennyi befér a videomemóriába, mert a valóságban a nagy jelenetnek csak egy kis részéről készül a képkocka, így elég azokat az adatokat tárolni, amelyek a leképezéshez kellenek. Emiatt a modern videojáték-motorok streaminget alkalmaznak, vagyis a nem szükséges adatokat a rendszermemóriában tárolják, és ha szükség van rájuk, akkor betöltik. A lost allocations bevezetésével a VMA 2.0 tulajdonképpen lehetővé teszi ezt a fajta menedzsmentet a Vulkan API alatt. Ez azért fontos lépés, mert igen nehéz jól megvalósítani a streaminget egy explicit API-val, a fejlesztők nyilván próbálkoznak, így viszont választható a VMA 2.0 is a saját kód helyett.
A másik fontos újítás a defragmentáció bevezetése. Az allokációk létrehozása és törlése folyamatosan zajlik a videomemóriában, és egy idő után a fedélzeti tár eléggé töredezetté válik. Mondhatni az allokációk között amolyan lyukak keletkeznek, ahova nem feltétlenül fér be egy új allokáció. Ezek azért is jelentenek problémát, mert így a felhasználható videomemória mennyisége folyamatosan csökken, elvégre hiába van például összeadva viszonylag sok memóriakapacitás szabadon, ha ezek nem alkotnak egy egybefüggő, allokálható területet. A defragmentációval az egyes allokációk egymásra tolhatók, hogy aztán a szabad memóriaterület egybefüggően legyen hozzáférhető és ezzel allokálható. Ennél a funkciónál fontos tényező, hogy csak az úgynevezett HOST_VISIBLE memóriatípusnál használható, illetve ha a defragmentált területen vannak pufferek és képobjektumok, akkor ezeket ki kell törölni, majd újra létre kell hozni és újra be kell kötni. A modernebb videojáték-motorok is jellemzően tartalmaznak ilyen megoldást, de mostantól nem feltétlenül kell ezt önállóan megírni, elég a VMA 2.0-ban használt kódot beépíteni.
Értékes újítás még a persistently mapped memory, amely egy Vulkan API-ban jellemzően előkerülő problémára reflektál. Leképezett memória használatakor elképzelhető, hogy két allokáció lesz hozzárendelve ugyanahhoz az eszközszintű memóriablokkhoz. Ha egyszerre történik a leképezésük, akkor az kellemetlen, ugyanis a Vulkan API nem engedi meg egy adott memóriablokk többszöri leképezését, így az alkalmazás egy hibaüzenettel kilép. A persistently mapped memory ezt a helyzetet kezeli egy speciális flaggel, így a fejlesztőknek erről sem kell közvetlenül gondoskodniuk.
Végül további extrák az egyedi memóriakészletek. A függvénykönyvtár eredetileg is automatikusan hozta létre és menedzselte az alapértelmezett memóriakészleteket az egyes, eszközön elérhető memóriatípusokhoz, de mostantól egyedi memóriakészletek is létrehozhatók. Ezzel lehetővé válik a fejlesztők számára a bizonyos típusú allokációk elszeparálása a többitől, kényszeríthetők egy adott méretre a memóriablokkok, illetve limitálható a memória kapacitása az adott memóriakészletre. Összességében ez az egész számos optimalizálásra ad lehetőséget, amelynek az alapjait a fejlesztőknek mostantól nem kell közvetlenül megírniuk, elég használni a VMA 2.0-t.
A Vulkan Memory Allocator 2.0 még változhat, de az aktuális kód már használható. Az AMD elsődlegesen fejlesztői visszajelzéseket vár. Maga a függvénykönyvtár továbbra is gyártótól független, így akármilyen grafikus vezérlővel üzemképes, továbbá a nyílt forráskód is megmaradt, tehát tetszőlegesen módosítható.
