Ez az oldal a közösségért készül. 
Kövess minket máshol is: 
Ha hasznosnak találod, és szeretnéd, hogy folytatódjon, támogasd a munkát 
A múlt héten megjelent az AMD ROCm 7.14 az első olyan production release-ként, amelyet már a TheRock-ra építettek, és már most látszik, hogy a ROCm stack jövőjében további újdonságokra lehet számítani. Különösen ígéretes, hogy a SPIR-V a ROCm-mel együtt valósággá válik: egységes binárisok készülhetnek, amelyek több grafikus architektúrán/célplatformon is működnek, javul a hordozhatóság a különböző GPU hardverek között, és általában is jobb lesz az élmény egy egységes IR célzása mellett.
A SPIR-V az a köztes reprezentáció, amelyet leginkább a Vulkan API driverekkel szoktak összekapcsolni, de más Khronos API-k – például az OpenGL és az OpenCL – is támogatják. Az AMD ROCm egy olyan modell felé halad, amelyben a SPIR-V IR-t ROCm alatt is támogatja, hogy ne kelljen minden egyes GPU-célra külön buildet készíteni, és egységesebb legyen a fejlesztői élmény. Ennek azonban ára van: az első futtatáskor nagyobb JIT késleltetés jelentkezik, amikor egy adott GPU eszköz/cél esetén először történik kernel hívás, és kezelni kell azokat a kódrészeket, amelyek fordítási időben architektúra-specifikus elemeket tartalmaznak.
A SPIR-V és a ROCm összekapcsolása régóta készül, és az MLIR-stratégia része is. A témával az elmúlt években többször is foglalkoztunk a Phoronixon, ahogy kirajzolódott ez az irány, és egyre közelebb került a SPIR-V támogatása ROCm alatt...
Az AMD egységes AI szoftver stackje nagyon nagy dobás lehet,
az AMD ROCm 6.4 SPIR-V linking támogatást ad a HIP-hez, miközben az AMD SPIR-V vendor-specifikus változatának támogatása megérkezett az LLVM-be,
Az AMD ma blogbejegyzésben foglalta össze, hol tart jelenleg a SPIR-V támogatás a ROCm-ben, és mi várható a folytatásban. A ROCm 7.2 és az annál újabb verziók már tartalmazzák az alapvető támogatást, például az AMD GCN SPIR-V targetet az LLVM/Clang-ben, a SPIRV-LLVM Translator útvonal ma már production szintű, és működik a folyamatonkénti JIT cache-elés is. A következő lépés, hogy az LLVM beépített SPIR-V back-endje váltsa fel a translatort, és ez legyen az alapértelmezett lowering útvonal. Továbbra is dolgoznak a JIT-fordításon csomagszintű telepítéskor, valamint a debug élmény javításán a SPIR-V AMDGCN JIT útvonalon. Meg kell oldani a SPIR-V buildet az architektúránkénti device library-khez is.
A kilátások biztatóak: egyetlen AMD ROCm bináris „csak működik” majd sokféle GPU-n, a buildidő és a bináris mérete kiegyenlített marad, „ingyen” jár a forward kompatibilitás, gyors lesz a teljesítmény, és széles körű lesz a library-támogatás. A SPIR-V-re épülő ROCm stack már most is sikeresnek bizonyult a PyTorch esetében.
További részletek a SPIR-V-re épülő ROCm stackről a nemrég megjelent blogbejegyzésben olvashatók. Várhatóan a héten, a kaliforniai AMD Advancing AI rendezvényen is hallunk majd többet a SPIR-V-vel kapcsolatos terveikről.
