Betekintés az NVIDIA Volta architektúra képességeibe

A vállalat csak a gépi tanulásra fókuszált az új lapkánál, ami érdekes dizájnt szült.

Gépi tanulás mindenek felett

Az NVIDIA a tegnapi napon bemutatta a Tesla V100 jelzésű gyorsítót, amelyről az alábbi hírben írtunk, és ígéretet tettünk arra, hogy később elemezzük magát a lapkát is, amit most meg is teszünk.

A GV100
A GV100 [+]

A Volta architektúra alapvető reformnak tekinthető a Pascal architektúrához viszonyítva, ugyanis az elsődleges fejlesztési tényező a gépi tanulásra vonatkozó igények minél hatékonyabb kiszolgálása volt. Ebben ugyan a Pascal elég jól működött, de messze nem olyan jól, mint egyébként kellene, emiatt a tervezés minden egyes pontját a hatékonyság növelésének szentelte a vállalat. A GV100 kódnevű lapka esetében alapvető újdonság a TSMC 12 nm-es gyártástechnológiája, ami szám szerint nagy előrelépésnek hangzik, de képességei tekintetében valójában nagyon közel áll az eddig használt 16 nm-es FinFET-hez, ugyanakkor egy 21 milliárd tranzisztorból álló, 815 mm²-es lapkánál a nüansznyi változások is fontosak. A fejlesztés következtében 84 darab streaming multiprocesszort sikerült beépíteni, amit az NVIDIA hivatalosan SM-nek jelöl, de ezúttal is előkerült már pár előadáson az SMV név, ami a Volta streaming multiprocesszor rövidítése.

A streaming multiprocesszorok felépítése szintén megváltozott a Pascal architektúrához képest, ugyanis amíg ez a Maxwell generációnál alkalmazott négyről kettőre csökkentette az említett egységeken belüli compute blokkok számát, addig a Volta esetében az NVIDIA visszaemelte ezt négyre. Igen ám, de a korábbi architektúrákhoz képest a compute blokkok felépítése nagyon megváltozott, és mostantól sokkal több szeparált futószalag van bennük kialakítva. Ez azért van, mert korábban a vállalat az egyes feladatokat megpróbálta multifunkciós és multipreciziós ALU-kkal megoldani, de a Volta fő fejlesztése az, hogy ezeket az ALU-kat leegyszerűsíti, és az egyes főbb feladatokhoz különálló egységet rendel, melyeket különálló futószalagra húznak fel. Ennek vannak előnyei és hátrányai is, nem véletlenül alakultak ki a különböző fejlesztési irányok. A fontosabb feladatokra szeparált ALU-kat használó dizájn elsődleges előnye, hogy egyszerűsíti az architektúra tervezhetőségét, az egyes feladatoknál növeli a hatékonyságot, illetve kevésbé komplex ütemező beépítését teszi szükségessé. A hátrány leginkább a komplex programokban jelenik meg, ahol nem tipikusan egy specifikus feladat végrehajtása zajlik, és ebben az esetben ez a hardveres dizájn kevésbé hatékony, mintha a rendszer multifunkciós és multipreciziós ALU-kkal lenne felszerelve.

Az új SM
Az új SM [+]

Az NVIDIA szempontjából a váltás így is megéri, mert a gépi tanulás egy rendkívül kiszámítható feladat, gyakorlatilag 95%-ban mátrixszorzás, tehát ahhoz, hogy egy hardver igazán jól működjön benne, mindent a mátrixszorzás hatékony végrehajtásának kell alárendelni. A többi műveletben még bevállalható az is, hogy a hatékonyság csökkenjen, mivel a mátrixszorzásokon a rendszer az ebből eredő hátrányt úgyis behozza. Emiatt szeparálta a vállalat a feldolgozókat, ugyanis a gépi tanulás szempontjából ez kritikus, a többi igény pedig, úgy néz ki, annyira nem számít.

Megújult compute blokk

A compute blokkok természetesen rendelkeznek egy utasítás pufferrel is, amit ezúttal L0 gyorsítótárként nevez az NVIDIA, és ezek a streaming multiprocesszor L1 gyorsítótárát egészítik ki. Ami viszont fontos változás, hogy módosult a GigaThread motor ütemezése. Az újítás itt a szálak teljesen független ütemezése, ami az NVIDIA architektúráinak egy régi problémájára reagál. Nevezetesen arról van szó, hogy a korábbi architektúrák, ezen belül is a Pascal warpja (vagy wave-je, kinek hogy tetszik) az összes szál között egy programszámlálót osztott meg, és tartozott még ehhez egy speciális maszk is, ami azt határozta meg, hogy a warpon belül melyik szál aktív az adott időben. Ez viszont egy feltételes végrehajtás során problémás, mert számos szálat a warpban inaktívvá tesz, ugyanis csak az egyik feltételre vonatkozó szálakat tudja párhuzamosan futtatni, tehát az összes szál nem futhat egyszerre, amíg az eredeti maszk visszaállításra nem kerül. A Volta esetében a warp minden szála független ütemezést használ, így lehetővé válik a komplex algoritmusok sokkal általánosabb leprogramozása, emiatt – többek között – nem szükséges mindenáron elkerülni a finomszemcsés szinkronizációt alkalmazó algoritmusokat.

Az új compute blokk
Az új compute blokk [+]

A compute blokkokra rátérve egy ilyen egységben egy feladatirányító (dispatch) és egy warp ütemező található, amelyek többféle futószalagot etetnek. Az NVIDIA ugyan még mindig használja itt a CUDA mag kifejezést, de ez egyre inkább értelmetlenné válik, mivel amíg korábban egy CUDA mag egy komplex feldolgozó volt egy integer és egy lebegőpontos végrehajtásra tervezett ALU-val, addig a Volta esetében ez teljesen megváltozott. Az új architektúrában az utasításszavak végrehajtása a nekik megfelelő futószalagon történik. Ha 64 bites lebegőpontos operációról, azaz FP64-ről van szó, akkor egy darab 8 utas, FP32 esetében már egy darab 16 utas, integer mellett egy darab szintén 16 utas, míg az új Tensor műveleteknél egy darab 128 utas tömb áll rendelkezésre. Utóbbi esetben fontos kiemelni, hogy ezek strukturálva vannak, vagyis egy 128 utas tömb gyakorlatilag két darab úgynevezett tensor magot jelent, amelyek 64-64 darab ALU-t használnak. Ezek a tensor magok egyébként speciálisan gépi tanuláshoz, ezen belül is mátrixaritmetikára tervezett, kevert pontosságú feldolgozók.

Az NVIDIA CUDA magoknak az FP32-es ALU-kat tartja, ami elég sarkított nézet, ha azt tekintjük, hogy korábban ez egyszerre jelentett lebegőpontos és integer ALU-kat. Ezek tehát már nem CUDA magok, de vélhetően az egyszerűbb magyarázat érdekében a korábban bevezetett elnevezéseket valamire rá kellett illeszteni. Az FP32 ALU-k egyébként IEEE754-2008-as szabványnak megfelelők, és támogatják a MAD (Multiply-Add), illetve az FMA (Fused Multiply-Add) instrukciókat. Ezek az ALU-k támogatják az FP16-os műveleteket is, méghozzá úgy, hogy egy FP32-es feldolgozó két darab, egymástól nem függő 16 bites lebegőpontos operációt hajthat végre. A compute blokkokon belül átalakult a load/store egységek bekötése is, így ezek mostantól az előző bekezdésben található tömbök részei, azaz mind a négy, alapvetően eltérő képességű tömbhöz két-két ilyen egység tartozik, és ugyanígy egy-egy speciális funkciókért felelő egység (SFU) is bekötésre került, amelyek a trigonometrikus és transzcendens utasításokat hajthatják végre. Utóbbi változásoknak az a magyarázata, hogy a feladatirányító egységek száma compute blokkonként a korábbi kettőről egyre csökkent, így logikus volt a független load/store és SFU futószalagokat a tényleges feldolgozótömbök részévé tenni, mivel így ezek vezérlése is egyszerűsödik. Nem mellesleg az interpolációt a Volta már manuálisan végzi, vagyis az SFU-kból ez a lehetőség kikerült.

A compute blokkokban fontos változás, hogy a Pascal dizájnjához képest felére csökkent a közös regiszterterület mérete, aminek kapacitása így 64 kB lett. Ennek az oka, hogy egy compute blokkban feleannyi integer és FP32 ALU található, mint a Pascal esetében, tehát csak ehhez igazodott az NVIDIA, vagyis arányaiban igazából nem történt változás. Módosult a helyi adatmegosztás is, mivel az új shader multiprocesszor a Pascalban alkalmazott opciónál kétszer több, 128 kB-os helyi adatmegosztással (Local Data Share) rendelkezik. Ugyanakkor ez szintén nem jelent arányaiban változást, mivel a compute blokkok száma is megduplázódott, így egy blokkra továbbra is 32 kB-nyi terület jut.

A GV100 a textúrázási képességek területén nem újít igazán. Az egyes streaming multiprocesszorok egy darab textúrázó blokkot tartalmaznak, amelyet négy compute blokk használ egyszerre. Lényeges különbség azonban a Pascal dizájnjához képest, hogy a textúrázó blokkokhoz ezúttal nem tartozik különálló, írható és olvasható L1 gyorsítótár, így erre a feladatra a helyi adatmegosztáshoz kialakított memória van befogva. Ennek a célja egyértelműen a tranzisztorokon való spórolás, mivel a rendszer előnyére egyáltalán nem válik, de túl nagy lett így is maga a lapka, tehát bizonyos területeken muszáj volt nagyobb kompromisszumokat kötni.

A motorháztető alatti titok

A GV100 az előző GP100-hoz képest nem sokat változott a memóriaalrendszer tekintetében. Megmaradt a méretes interposer, illetve még nagyobb lett, és ezen négy darab, egyenként 4 GB-os, azaz összesen 16 GB HBM2 memória kerül. Ebből kitalálható, hogy 4096 bites a memóriabusz, mivel a négy darab memóriatömb egyenként 1024 bites buszon keresztül kapcsolódik a GPU-hoz, illetve a lapka kapott még 6 MB L2 gyorsítótárat is.

Az NVLINK szintén megmarad, méghozzá modernizált formában. Ez az összeköttetés a GV100-on belül továbbra is HUB által lesz vezérelve, de az interfész egy irányba a korábbi 20 GB/s-os helyett már 25 GB/s-ot tud. Emellett maga a lapka hat darab NVLINK interfészt kezel, így az összteljesítmény elérheti a 300 GB/s-ot, de ez nagyban függ a konfiguráció formájától, így általánosítani nem lehet.

A GV100-at a GP100-hoz hasonlóan kétféleképp lehet beépíteni a szerverekbe. Egyrészt használhatók olyan processzorok, amelyek minimum x16-os PCI Express 3.0-s vezérlővel rendelkeznek. Ilyenkor egy processzorra a megfelelő PCI Express átkapcsolóval akár két GV100 is köthető, de a szerverprocesszorok esetében azért jellemzően jóval több PCI Express 3.0-s csatorna is használható. Az NVIDIA a megfelelő NVLINK topológia miatt processzoronként maximum hat GV100 lapkát enged meg.

Igazán izgalmassá akkor válik a helyzet, ha IBM Power9 architektúrára épülő, NVLINK interfészt is támogató processzorok mellé kerül a GV100. Az új lapkában ugyanis van ATS (Address Translation Services) támogatás, ami lehetővé teszi a GV100-as GPU-nak, hogy közvetlenül elérhesse a CPU-k laptábláit. Ennek az eljárásnak az ismertebb, amolyan általános neve a general purpose memory paging (GPMP), és tulajdonképpen lehetővé teszi azt, hogy a hardver automatikusan kezelje a memória menedzsmentjét, így ezzel az amúgy igen bonyolult problémával a fejlesztőknek nem kell foglalkozniuk. Magasan ez a Volta architektúra legértékesebb fejlesztése, ami várható is volt, mert ennek a némileg limitált, lényegében csak a CUDA platformon működő verzióját a GP100 már tartalmazta, de a GV100-ban egy platformtól független megoldás van a problémára, így ez sokkal nagyobb szerephez juthat.

A tényleges termékre rátérve a Tesla V100 nem teljes értékű GV100-at használ, mivel a lehetséges 84 shader multiprocesszorból csak 80 lesz aktív. Ez persze nem nagy probléma, és elsődlegesen arra szolgál, hogy a gyártás során keletkező selejtes GPU-kat a hibás területek letiltásával el lehessen adni. Ez egy 815 mm²-es GPU-nál kritikus tényező, mivel elég sok lesz a selejt pusztán a lapka kiterjedése miatt is.

NVIDIA Tesla V100
NVIDIA Tesla V100 [+]

80 darab SMV-vel számolva a 300 wattos TDP fogyasztási osztályba sorolt Tesla V100-ban összesen 5120 darab CUDA mag lesz, de ahogy leírtuk, ez nem igazán mond semmit a lapkáról, így jobban strukturálva 5120 darab FP32-es, 5120 darab integer, 2560 darab FP64-es, valamint 40 960 darab tensor feldolgozó kapott helyett a rendszerben. A textúrázó csatornák száma összesen 336, míg a teljes memóriabusz 4096 bites. Az NVIDIA turbó órajelnek 1455 MHz-et tervez, ezzel számolva jön ki a 7,5 TFLOPS-os, 15 TFLOPS-os, 30 TFLOPS-os és 120 Tensor TFLOPS-os elméleti teljesítményadat a 64 bites, 32 bites és 16 bites lebegőpontos számítások, illetve az új Tensor magok mellett. Az NVIDIA megadta a memória effektív órajelét is, amely 1,75 GHz lesz, így a memória-sávszélesség 900 GB/s, mindemellett az ECC is támogatott.

Abu85

Azóta történt

Előzmények

Hirdetés