Az AMD az idei SC15-tel kapcsolatban nagyon titkolózott, de arra korábban is utaltak, hogy egy nagy dologgal készülnek, bár a legtöbben hardvert vártak. Valójában azonban egy Boltzmann Initiative névre keresztelt szoftvercsomagot kap a piac, amely viszont több szempontból is sokkal érdekesebb bármilyen hardvernél.
Mint ismeretes, az AMD a FirePro S termékcsaládba sorolt gyorsítói a piac leghatékonyabb és leggyorsabb megoldásai. A FirePro S9170 2,62 TFLOPS-os dupla pontosság melletti teljesítményét egyetlen más aktuálisan kapható gyorsítót sem tudja megközelíteni. A legközelebb az NVIDIA Tesla K80 jutott 1,87 TFLOPS-szal, de ezt két GPU használatával sikerült elérni, míg az említett FirePro egy GPU-val operál. Az AMD ezt a technikai előnyt formális sikerekbe tudta átönteni, mint például a green500.org listájának egy ideig történő uralása.
A problémát jellemzően az jelenti, hogy a HPC-piac az OpenCL-lel nem igazán foglalkozik, ami persze változhat, de ez egy olyan nyelv, aminek nem sikerült megvetnie a lábát ezen a területen. Ennek nyilván köze van ahhoz is, hogy túl sok kódot kellene átírni, amit sokan nem szeretnének megtenni. Némileg javított az AMD helyzetén a PathScale ENZO fordító, amely lehetővé tette az OpenMP 4.0-s API-n keresztül a HPC szerverekben használt C/C++ és Fortran kódok futtatását a FirePro S termékcsalád képviselőin. Erre építve a vállalat meg tudta támadni az olaj és gáz utáni kutatások területét, mivel az RTM (reverse time migration) technika használatát egyszerűen tudták GPGPU-ra átültetni, és ebben a GCN architektúra nagyon erős.
Látni kell azonban, hogy GPGPU-s szempontból a HPC-piacon a CUDA számít elterjednek, és az AMD-nek erre a problémára reagálnia kellett. A vállalat alapvető megoldása a HCC, vagyis a Heterogeneous Compute Compiler, ami az LLVM, a Clang és a HSA köré épül, és a koncepció célja, hogy lehetővé tegye a fejlesztőknek a CPU-k és a GPU-k egyetlen nyelvből és egyetlen forrásból való kiszolgálását. A támogatott nyelvek között a C++11/14, C11 és OpenMP 4.0 szerepel. A HCC nagy előnye az OpenCL 2.0-val szemben, hogy utóbbi a GPU kernelek esetében még mindig külön forrás igényel, de a HCC már nem.
A HCC fordítót az AMD a GCN architektúrához építette, és a korábbi, jellemzően harmadik féltől származó fordítókkal ellentétben jelentős optimalizálásokat tartalmaz a rendszer aszinkron compute képességeihez, illetve a CPU-khoz hasonlítható gyorsítótárstruktúrájához.
[+]
A Boltzmann Initiative szoftvercsomag alapvető eleme még a HIP, amely a Heterogeneous-compute Interface for Portability rövidítése. Ez biztosítja a kódok portolhatóságát az egyes fordítók között. Ha a koncepciót valamihez hasonlítani akarjuk, akkor a legjobb példa a SYCL, bár ennek az aktuálisan elérhető 1.2-es verziójánál jóval többet tud. Első körben a HIP forrásból a HCC képes AMD, míg az NVCC NVIDIA hardvereken futó binárist fordítani. Ilyen formában a fejlesztőknek gyakorlatilag csak HIP forráskódot kellene írni, és a hardverek tetszőlegesen cserélhetővé válnak. Nagyon sok forráskód azonban CUDA alapú, ami a váltást megnehezíti, de az AMD emiatt tervezte meg a HIPify eszközöket, amelyek a CUDA forráskódot képesek HIP forráskódra konvertálni. Az eddigi tesztek szerint a megírt kódok 90%-a ilyen formában úgy konvertálható, hogy a futtatás problémamentes legyen az AMD hardverein, miközben a sebesség ne romoljon az NVDIA megoldásain. Bizonyos specifikus források esetében azonban érdemes módosítani a konvertált HIP forráskódot, de ez már így is nagyságrendekkel kevesebb munkával jár, mintha teljesen át kellene portolni a programot.
Az AMD szerint a HIPify eszközökkel konvertált forráskód a CUDA forráskódok teljesítményét is megőrzi, így gyakorlatilag a GCN architektúrára épülő FirePro hardvereken a teljesítmény csak akkor csökkenhet, ha az adott CUDA forráskód nagyon GPU-specifikus, vagyis kifejezetten egy, az adott szerverben megtalálható GPU-ra van kigyúrva. Ugyanakkor még így is érdemes próbálkozni a konvertálással, mivel a FirePro modellek nyers teljesítménye dupla pontosság mellett annyival nagyobb a hasonló kategóriába sorolt Tesla modelleknél, hogy a nem optimalizált CUDA forráskód is gyorsabban futhat az AMD hardverein. Ez azonban tényleg nagyon függ a specifikus optimalizálás jellegétől.
A fentiek miatt az NVIDIA reakciója kiszámíthatatlan lesz, de az AMD jogi lépésektől nem tart, amit azzal támasztanak alá, hogy a Google is bemutatta a saját, LLVM-re épített GPUCC fordítóját, amely a CUDA kódokat lefordítja a különböző GPU-architektúrákra. Ez gyakorlatilag majdnem ugyanaz, amit a HCC csinál, de annyi különbség azért van, hogy az AMD HCC fordítója rendkívül teljesítménycentrikus és a GCN architektúrákra nagyon gyors kódokat fordít.
[+]
A Boltzmann Initiative szoftvercsomag része még a headless 64 bites Linux meghajtó, illetve a HSA+ futtatási környezet is. Utóbbi a HSA 1.0-s platform specifikációnak kiterjesztése. Annak érdekében, hogy a HSA-t ne fenyegesse a fragmentáció veszélye, a HSA+ nem kompatibilis vele, vagyis ez teljes mértékben az AMD magánakciója, noha rengeteg dolgot felhasznál a véglegesített specifikációkból, de a cél az eredeti platform kiterjesztése a dedikált gyorsítókra. A HSA+ is nyílt forrású kezdeményezés lesz, így ebből a szempontból a piac igényeinek megfelel.
Megjegyezendő, hogy a Boltzmann Initiative szoftvercsomag részeként a HCC kétféle opciót kínál a programozásra. Az egyik a C++ AMP-hez rendkívül hasonlító explicit szintaxis a párhuzamos operációkhoz. Ezzel megírható úgy egy kódszegmens, hogy az párhuzamosan fusson, és definiálható, hogy miképpen működjön a program többi részével. A másik metódus a Parallel STL kihasználása, amely C++17 fő újításának van beharangozva. Ez számos párhuzamosítható szabványos funkció futtatását teszi lehetővé a gyorsítókon, így a fejlesztőknek nem kell közvetlenül kontrollálni a párhuzamos programfuttatást.
Az AMD a Boltzmann Initiative szoftvercsomagot a következő esztendő első negyedévében fogja szállítani az érdeklődő partnereknek. A vállalat kihangsúlyozta, hogy az újítások mellett az OpenCL platform támogatása sem vész el, így ez is maradhat befektetési cél.
