A Khronos Group ismét főszereplő az idei SIGGRAPH-on, ahol tradicionálisan bejelentésekkel szoktak érkezni. Ez most sem maradt el, bár inkább csak a készülő fejlesztésekről volt szó, mint igazán lényeges konkrétumokról.
A legfontosabb tényező, hogy végleges állapotba került az NNEF (Neural Net Exchange Format) 1.0-s szabvány, amely az első egységes neuronháló fájlformátum. Ezt a gépi tanulás piaca igen régóta várja, hiszen komoly szerepe lehet abban, hogy megszüntesse a szegmensben jelenleg uralkodó fragmentációt. Mint ismeretes, ma komolyan korlátozza az ipar fejlődését a tréning és a dedukció szakaszok közötti interoperabilitás hiánya. Jelenleg kifejezetten problémás ez a terület, ugyanis a különböző, neuronhálók létrehozását biztosító keretrendszereknek az összes elérhető gyorsítóra különálló támogatást kell írni. Ez nagyrészt amiatt van így, mert nincs az iparon belül megegyezés a hálózat formai szemantikáiról, a struktúrájáról, az adatformátumokról, illetve a sűrűn használt operációkról. Ezáltal minden keretrendszer eltérő ebből a szempontból, és egyedi hardveres támogatást kell tervezni a dedukció szakaszára is.
[+]
A konzorcium által kialakított modell szerint NNEF-et direkten célozhatják a manapság használt keretrendszerek, amelyek az OpenCL, a SYCL, a CUDA, a HIP, és még más meg nem nevezett platformok alól gyorsíthatók a különböző hardvereken az ezekhez való könyvtárakon keresztül (NVIDIA cuDNN, AMD MIOpen, Intel MKL-DNN, stb.). Az NNEF-et használva lényegében a tréningre használt neurális hálók kimenete lesz egységes, amit elfogadnának a dedukcióra bevetett gyorsítók, függetlenül attól, hogy a tréning milyen platformon történt meg. Innentől kezdve már ismét számos gyártófüggetlen szabvány áll rendelkezésre a működés biztosítására, kiemelve az OpenVX-et, az OpenCL-t és a Vulkan API-t, amelyekkel a dedukció szakasza gyorsítható a különféle hardvereken.
A Khronos Group az elmúlt éves munkával nagyon elégedett, az iparág jelentős része, konkrétan 32 szereplője már biztosította a konzorciumot a szabvány támogatásáról.
A VR- és AR-piacot célzó OpenXR 1.0 fejlesztése jól halad, a rendezvényen már demonstrációkat is tartanak vele, így a következő lépcső az előzetes specifikáció megalkotása. Erre valószínűleg még idén sor fog kerülni, a véglegesítés viszont majd csak jövőre esedékes, legjobb esetben is egy év múlva.
[+]
A grafikus API-k tekintetében a Khronos Group lényeges bejelentéssel nem élt, de a Vulkan esetében folyamatos tárgyalások vannak az újításokkal kapcsolatban. Jelen pillanatban az FP16 és az INT8 operációk támogatásának teljes szabványosítása jelenti a fő célt, ugyanis bizonyos újabb hardverek már alkalmasak ezek végrehajtására. Emellett persze számos potenciális újításra vonatkozóan zajlanak tárgyalások, többek között a sugárkövetésre is, de az API-ban történő szabványos elérhetőség még nagyon messze van. Ebből a szempontból a Khronos Group eléggé lemaradt a Microsoft mögött, hiszen a DirectX Raytracing, a Direct 12 sugárkövetésre vonatkozó szabványos kiegészítése az év végén elérhető lesz az új Windows 10 frissítésben. A Vulkan persze így sem maradt teljesen sugárkövetés nélkül, hiszen már hozzáférhető az AMD saját implementációja, de ez nem tekinthető szabványosnak, akkor sem, ha elméletben gyártófüggetlen.
[+]
Végül lényeges bejelentés, hogy kezd körvonalazódni az OpenCL jövője. A Khronos Group alapvetően két problémát érzékel a rendszerrel kapcsolatban. Az egyik, hogy az OpenCL nem érhető el mindenhol. Ez igazából nem lesz másképpen, túl komplikáltak az API igényei ahhoz, hogy például az Androidon megvesse a lábát. Ugyanakkor számos szoftvercég épít az OpenCL-re, ami azért baj, mert a már megírt OpenCL C kódokat nehezen tudják Androidra mozgatni. Ezt a problémát a Khronos Group úgy kezelné, hogy a Vulkan futtatási környezetet tennék egyre inkább alkalmassá arra, hogy az OpenCL C kódokat átfogóan támogassa. Erre van többek között a Clspv fordító, ami már megoldja a kódok egy részének futtathatóságát egy szabványos Vulkan implementáción, de később ez még fejlődni fog. A cél itt az, hogy a korábban OpenCL-t választó szoftverfejlesztők viszonylag kis befektetéssel is újra tudják hasznosítani a már megírt OpenCL C kódjaikat egy olyan platformokon, ahol OpenCL API hivatalosan nincs, de Vulkan pont van. Alternatív lehetőség a futtatási időben történő fordítás, de ez egyelőre még képlékeny, viszont van realitása, így érdeklődés mellett a Khronos Group nem zárkózik el a megvalósításától.
[+]
A másik probléma az, hogy az OpenCL a 2.0-s specifikáció óta túl sokat kér, így alig van gyártó, amely ennek maradéktalanul meg tud felelni. Az új OpenCL esetében a gyártók kiválaszthatják azokat a komponenseket, amelyeket támogatni tudnak, illetve akarnak, és a Khronos Group csak azt fogja majd vizsgálni. Emellett a konzorcium kijelöl majd saját profilokat is, vagyis a meglévő alkalmazásokat nem kell majd újraírni.
Az új OpenCL bemutatása a következő év során várható, akkor majd többet meg lehet tudni a hátterében meghúzódó koncepcióról.
