A Khronos Group a bejelentette a Vulkan API 1.1.82-es specifikációját, ami némi hibajavítás mellett elérhetővé tette az VK_NV_device_diagnostic_checkpoints kiterjesztést.

Az újítás lényege segíteni a fejlesztők munkáját, vagyis a felhasználók nem sok előnyét fogják érezni, közvetlenül legalábbis semmiképpen. A lényeg annyi, hogy az explicit API-k esetében gondot jelenthet, hogy az erőforrás elvesztését okozó problémákat nem mindig egyszerű feltérképezni. Ez azért van, mert az új API-k működése rengeteg többletterhelést levesz a processzor válláról, és ezek jellemzően olyan feladatok voltak a hagyományos API-kban, amelyek valamit ellenőriztek. Többek között például az OpenGL-ben minden függvényhívás belsőleg volt hitelesítve, és ha valami nem sikerült, akkor egy hibakód jelezte a probléma forrását, illetve az eszközillesztő leállása esetén nem is feltétlenül az alkalmazás lehetett a bűnös. Ennek megvolt a szépsége és az árnyoldala is, gyakorlatilag minden hiba behatárolható volt, viszont sok problémát a program oldalán ki sem lehetett javítani.

Az explicit API-k esetében a fejlesztő nagyobb kontrollt kapott, ami nem azt jelenti, hogy az API bizonyos függvények helytelen használatakor nem ad vissza valamilyen hibakódot, de ez csak korlátozott esetekre vonatkozik, például egy parancs felvétele a parancspufferbe teljesen az alkalmazás felelőssége, ha rosszul csinálja, akkor az hibához fog vezetni, ráadásul semmi támpont nem lesz a gond kiszűrésére. Az egész helyzetet nehezíti, hogy a validációs rétegek sem szúrnak ki mindent, persze ezek fejlődnek, de elképzelhető, hogy egy alkalmazás olyan tevékenységre kényszeríti a rendszert, ami egy gyártó implementációjának jó, míg egy másik cég meghajtóján az erőforrás elvesztését okozza. Szóval megadta magát a driver? Biztos az a rossz! Az explicit API-kkal azonban egy alkalmazás oldalán található gond is előidézheti ezt a jelenséget.

A kérdés az, hogy hol volt a hiba, pontosan melyik parancs váltotta ki az összeomlást? Ha az API nem ad hibakódot, akkor nyilván borzasztóan nehéz a probléma felkutatása. Szerencsére a Vulkan API eléggé rugalmas ahhoz, hogy magába a motorba be lehessen építeni egy úgynevezett crash debug funkciót, amit sok stúdió meg is tesz, illetve bizonyos gyártók extra kiterjesztést is adnak a jobb eredmények elérése érdekében, ilyen például a VK_AMD_buffer_marker.

Az NVIDIA most előállt egy saját megoldással, ami lényegében ugyanazt csinálja, amit az integrált crash debug opciók, csak éppen a külső Aftermath programon keresztül, és az első bekezdésben említett kiterjesztés azért szükséges, hogy a megfelelő információk mentésre kerüljenek, ha az alkalmazás futtatása közben összeomlik a Vulkan meghajtó.

A VK_NV_device_diagnostic_checkpoints természetesen beépíthető az egyes motorokba integrált crash debug megoldásokba is, elvégre kinyert adat a lényeg, az már nem annyira fontos, hogy milyen eszközökkel kutatják fel a hibát a fejlesztők.

A Vulkan 1.1.82-t a gyártók hamarosan implementálni fogják a meghajtóikba.