A Pascal részletesen
Az NVIDIA az idei évben már többször is elővette a Pascal architektúrát egy-egy bemutatón. Többek között a GP100-as verzió rejtelmeiről is írtunk már, de az egy HPC-piacra tervezett lapka, így csak egy szempontból lehetett vizsgálni. A GP104 kódnevű verzióra már GeForce termékcsalád is épül, így más szemszögből is elemezhető, hogy az NVIDIA milyen változásokat vitt véghez, és ezt felületesen a hónap elején már meg is tettük. Azóta azonban az apró, de annál fontosabb információk is napvilágot láttak, így ideje a részletesebb elemzésnek.
Ahogy korábban már leírtuk a Pascal architektúra tulajdonképpen nem tekinthető alapvető reformnak, csupán az elődnek számító Maxwell architektúra és a Fermi örökségének egybegyúrásáról van szó. Még kifejezőbben megfogalmazva a Maxwell generáció több ponton is vérzett jövőbiztosság szempontjából. Erről számtalan alkalommal írtunk, és három alapvető gondot lehetett felfedezni az architektúrán, amelyek az ütemezésre, a compute hatékonyságra, illetve az új API-k támogatására bonthatók le.
A legfontosabb változás, ami egyben az alap is, a Fermi örökségéhez való visszatérés az ütemezés szempontjából. Ez egyszerűen megmagyarázható, mivel a jövőben egyre több olyan program várható, amelyik a futtatás szempontjából kiszámíthatatlan. Ezt úgy érdemes felfogni, hogy egy játék működése a grafikai feldolgozás tekintetében nagyon is megjósolható, mivel a grafikus futószalag kötöttsége miatt a hardver jól kigyúrható a tipikus munkamenetekre. Itt nem kevés tranzisztort lehet spórolni, mivel az ütemezés így nagyrészt szoftveressé tehető, vagyis az egész konstrukció működését biztosító részek egy jelentős hányadát nem szükséges hardveresen implementálni. A gond akkor kezdődik, amikor a program valami kiszámíthatatlant csinál, azaz nem követi a kötött grafikus futószalagot. Ilyenek például a játékoknak azon futószalagjai, amelyek compute shadert futtatnak, ugyanis ezekre nem igazán lehet felkészülni egy nagyrészt szoftveres ütemezéssel. Mivel a játékokban a compute futószalagok száma folyamatosan nő, és a várakozások szerint idén már eléri a grafikai futószalagok számának 20-40%-át is, mindenképpen a hardveres ütemezés használata adja a legjobb eredményt.
A Pascal architektúra másik fontos változása a preempció terén következett be. Ez az a pont, ahol a Maxwell és a korábbi NVIDIA architektúrák rendkívül intenzíven véreztek, mivel az NVIDIA egy nagyon régi modellt alkalmazott, nevezetesen a rajzolási szintű preempciót. Ezzel a problémával viszonylag sokat foglalkoztunk, elsősorban a virtuális valóságot figyelembe véve, mivel ez az a terület, ahol a preempció minősége dönt a jó és a rossz élmény között.
Hirdetés
A probléma tulajdonképpen azzal kapcsolatos, hogy a korábbi GeForce termékcsaládok csak a rajzolási parancsok határainál voltak képesek üzemmódot váltani, ami konkrétan az elképzelhető legrosszabb eshetőség a virtuális valóság szempontjából. A megfelelően finom szemcsézettségű preempció hiányában ugyanis a timewarp lekésheti a szinkronablakot. A gondot az okozza, hogy nem minden rajzolás egységes, vagyis lehetnek olyan feladatok, amelyek az ezredmásodperc törtrésze alatt lefutnak, de olyanok is, amelyek akár 3-6 ezredmásodpercig is eltartanak. Utóbbi jelenti a problémát, mert a timewarp számítására nagyjából 1-3 ezredmásodpercnyi idő van a virtuális valóságon belül, míg az aszinkron timewarpra sincs több nagyjából 10 ezredmásodpercnél. Könnyen kitalálható, hogy ha egy timewarp beragad egy hosszú ideig tartó rajzolás mögé, akkor gyakorlatilag képtelenség, hogy időben elkészüljön. Az eredmény szempontjából a timewarp típusa is fontos. Ha a normál timewarp nem készült el, akkor a virtuális fejpozíció nem lesz elég közel ahhoz, ami a valós, míg ha az aszinkron timewarp csúszott le a szinkronablakról, akkor az az előző képkocka ismétlésével jár, vagyis konkrétan egy apróbb akadással.
Ráadásul maga a problémakör olyan extrém, hogy a nyers számok tekintetében akár minden rendben is lehet, mivel a szoftveres mérőprogramok nem veszik figyelembe a timewarpokat, vagyis tulajdonképpen bőven előfordulhat, hogy a hardver kipréseli magából az elvárt képfrissítési sebességet, csupán a virtuális valóságon belüli élmény lesz rosszabb minőségű az elvártnál, mert a szoftveres úton nem kimérhető timewarpokon már elcsúszik a munka.
[+]
Az NVIDIA a fenti problémára reagálva a Pascalban bevezet egy finomabb szemcsézettségű preempciós modellt, amely a vállalat elmondása szerint pixel- és utasításszinten teszi lehetővé az üzemmódváltást. Ez még mindig egyfajta durvaszemcsés preempciós modellhez hasonlítható, mivel a már megkezdett pixelt és utasítást be kell fejezni a váltás előtt, de az NVDIA szerint a grafikából compute módba való átváltás 100 mikromásodperc alatti időegységen belül megtörténik, ami nagy átlagban több százszor, kiugró esetekben pedig akár több ezerszer gyorsabb, mint amit a korábbi GeForce architektúrák kínáltak.
A preempció szempontjából az is megjegyzendő, hogy az Intel Gen9 és az AMD GCN3 architektúráin belül az üzemmódváltás még a Pascal architektúránál is majdnem százszor gyorsabban valósítható meg, ugyanis ezek az architektúrák a kérés beérkezésekor konkrétan képesek a feladatmegszakításra és a munkalementésre, vagyis nem kell megvárniuk a futtatott folyamat befejezését sem. Ugyanakkor ez nem akkora probléma, mint az első olvasatra látszik. Nyilván előnyös, ha a lehető legfinomabb szemcsézettségű a preempció, de a Maxwell-lel a gond inkább az volt, hogy maga a rendszer nem tudott kvázi valós időben reagálni a beérkező, kritikus fontosságú feladatokra. Ebből a szempontból a Pascal képességei is bőven elég jónak mondhatók ahhoz, hogy a virtuális valóságon belüli igényeket megfelelően lekezelje.
A GP104 részletesen
Az előző oldalon taglalt változások elsődleges ára a több tranzisztor, de szerencsére ez most megengedhetővé vált, ugyanis a GP104 már a TSMC 16 nm-es FF+ node-ján készül. Magában a lapkában egyébként 7,2 milliárd tranzisztor található és ez 314 mm²-es lapkaterületbe fért be. Ebbe 20 darab streaming multiprocesszort sikerült beépíteni, amit az NVIDIA mostantól hivatalosan is SMP-nek jelöl, ami a Pascal streaming multiprocesszor rövidítése. Ezek azonban nem egyeznek meg a nagyobbik, GP100-as Pascal szimplán SM-nek jelölt multiprocesszoraival.
NVIDIA GP104 [+]
A streaming multiprocesszorok felépítése a második generációs Maxwell architektúrában ismert megoldáshoz képest nem változott jelentősen. Ennek köszönhetően elmondható, hogy egy ilyen egységen belül megmaradt a négy darab compute blokk, amelyek közös utasítás gyorsítótárat használnak. Mindegyik compute blokk rendelkezik egy utasítás pufferrel, ami nyilvánvalóan az utasítás gyorsítótárból szerzi be az aktuális munkához szükséges információkat. Az egész rendszer Fermihez hasonló, komplex ütemezést használ, továbbá a GigaThread motor is átalakult a hardveres ütemezés megfelelő vezérlése érdekében.
A compute blokkokra rátérve egy ilyen egységben két feladatirányító (dispatch) és egy warp ütemező található, amelyek 32 darab, úgynevezett CUDA magot etetnek, így az utasításszavak 2 darab, 16 utas feldolgozón hajtódnak végre párhuzamosan. Mindegyik CUDA mag rendelkezik egy IEEE754-2008-as szabványnak megfelelő, 32 bites lebegőpontos végrehajtóval, amelyek támogatják a MAD (Multiply-Add) és az FMA (Fused Multiply-Add) instrukciókat. Ráadásul ezek az új CUDA magok olyan 32 bites ALU-kat használnak, amelyek nem egy, hanem két darab 16 bites lebegőpontos operációt is képesek végrehajtani, ugyanakkor ez a GeForce termékeken limitálva lesz, így az elérhető teljesítmény a 32 bites tempó hatvannegyed része. A compute blokkonon belül található még 8 darab speciális funkciókért felelő egység (SFU), amelyek a trigonometrikus és transzcendens utasítások mellett az interpoláció feladatát is elvégzik.
Az NVIDIA a dupla pontosságot a GP104-ben ugyanúgy oldja meg, ahogy ezt teszi a GM204-ben, azaz minden compute blokkhoz egy-egy darab speciális CUDA mag tartozik. Technikai értelemben ezek az SMP részei, viszont két-két speciális CUDA magon osztozik két-két compute blokk. Ennek következtében egy SMP-ben összesen négy dupla pontosságra tervezett mag található, ami a teljes lapkára nézve 80 feldolgozót eredményez.
A GP104 SMP-je [+]
A compute blokkoknál lényeges tényező, hogy az NVIDIA GP100-as verzióval ellentétben a GP104-ben már nem alkalmaz 128 kB-os közös regiszterterületet, így be kell érni 64 kB-tal, és ennyi van a Maxwell multiprocesszorainak compute blokkjaiban is. Erre a fájdalmas korlátozásra minden bizonnyal tranzisztortakarékosságból került sor, mindenesetre jobb lett volna a megduplázott kapacitás, mivel a Maxwell dizájnja eléggé regiszterszegénynek tekinthető az olyan újabb generációs videojáték-motoroknál, mint amit például az új Hitman használ.
A GP104 a textúrázási képességek területén nem újít igazán. Az egyes streaming multiprocesszorok két darab textúrázó blokkot tartalmaznak, és egy blokkot két compute blokk használ egyszerre. Egy textúrázó blokkhoz tartozik egy 24 kB-os kapacitású írható és olvasható L1 gyorsítótár, amelyet természetesen a CUDA magok is használhatnak. Maga a részegység egyébként négy darab textúrázócsatornát rejt, amely természetesen szűrt mintákkal is képes visszatérni.
A GP104-es dizájnnal a Pascal architektúra lényegében lemásolja a GM204-ben használt multiprocesszorok működését a helyi adatmegosztás terén. Emiatt az SMP modulok 96 kB-os Local Data Share tárolóval rendelkeznek, amelyen a négy darab compute blokk osztozik. Itt az NVIDIA továbbra is jelentős energiát takaríthat meg, hiszen technikai értelemben nem rendel direkt LDS-t az egyes compute blokkokhoz, tehát kevesebb tranzisztort is kell erre költeniük. Viszont a DirectCompute 5.0-s szabvány ezt a megoldást direkten nem támogatja, mivel a helyi adatmegosztáson egyszerre nem osztozhat több compute blokk, pontosabban fogalmazva több szálcsoport. Ezt a gondot most is egy trükkel hidalják át a tervezők, így a helyi adatmegosztás egyrészt továbbra is leosztható két 48 kB-os részre, ami két compute blokkot működtet relatíve nagy tárral. Ugyanakkor alternatív lehetőség három darab 32 kB-os részre osztani az LDS-t, amivel a négyből már három compute blokk is befogható. Természetesen más compute felületeken a helyi adatmegosztás továbbra is sokkal rugalmasabban használható, hiszen a fenti működés főleg a DirectCompute 5.0-s szabvány limitációiból keletkezik.
Memóriahierarchia szempontjából a GP104 nem igazán változott, így az architektúra továbbra is 2 MB kapacitású, megosztott L2 gyorsítótárat tartalmaz, amit mindegyik streaming multiprocesszor elérhet, és a CUDA magok írhatnak is bele. Ennek egy része most is a mozaikos optimalizálást segíti, amolyan lapkán belüli dedikált memóriaként.
Memóriavezérlő tekintetében az NVIDIA továbbra is maradt a crossbarnál. A GP104 256 bites szélességű buszt használ, ami két 32 bites csatornát tartalmazó 64 bites modulokra van szétosztva. Egy-egy modulhoz egy ROP-blokk tartozik. Utóbbiból összesen 4 darab van, ami 64 blending és 256 Z mintavételező egységet eredményez.
A compute és a grafika
A Pascal megváltozott a parancsmotorok terén is. A fő parancsprocesszor nyilván megmaradt, de ennek a képességeit is bővíteni kellett, mivel a DirectX 12 és a Vulkan API-k esetében jóval korlátozottabb lett az, hogy milyen parancsutakat lehet alkalmazni. A DirectX 12 konkrétan nem enged meg semmilyen alternatív, gyorsabb feldolgozást lehetővé tevő parancsutat sem, és egy ilyen alkalmazása a Vulkan esetében sem egyszerűbb, mivel teljes egészében az alkalmazás felel a vezérlésért. Emiatt több általános parancsutat kapott a rendszer, így megnőtt az a skálázhatóság, amit az új, explicit API-kkal el lehet érni. Emellett megújulnak a GMU-k, azaz a Grid Management Unitok is, így a Pascal jobb Hyper-Q képességekkel fog rendelkezni, mint a Maxwell. Ez egészen konkrétan azt is jelenti, hogy a GMU-k az operációk közötti szinkronizáció mellett támogatják az erőforrás-korlátozást is, ami a DirectX 12 és a Vulkan API-k esetében is hasznos, mivel ilyen formában az NVIDIA aszinkron módban is betölthet a GP104-be egy megfelelően időzített compute futószalagot. Ez tulajdonképpen az aszinkron compute néven emlegetett DXGI funkció hatékony támogatásához szükséges követelmény volt. Ezzel korrigálásra került a harmadik olyan terület is, ahol a Maxwell architektúra vérzett.
A compute és a grafikai futószalagok kezelése is módosult az architektúrán belül. Az aszinkron compute teljes hatékonyságához ugyanis ajánlott az is, hogy a compute parancsokat a rendszer speciális hardverállapotban kezelje. Az aktuális architektúrák ebből a szempontból nagyon különböznek. Például az Intel Gen7.5, Gen8 és Gen9 generációja képtelen egyszerre compute és grafikai parancsot futtatni, a teljes integrált grafikus vezérlőnek vagy az egyik, vagy a másik hardverállapotot kell felvennie. Ennek gyökeres ellentéte az AMD GCN architektúrája, amelynek minden iterációja úgynevezett stateless compute feldolgozást használ, vagyis a compute parancsokat akármilyen hardverállapotban képes futtatni, így akár egy multiprocesszoron belül is megoldható, hogy egyszerre fusson a grafikai és a compute futószalag, mindezt dinamikus erőforrás-menedzselés mellett, amiről egy beépített hardveres blokk gondoskodik.
Az NVIDIA a Maxwell architektúránál a két végpont közötti konstrukciót választott, vagyis a teljes grafikus vezérlő képes volt arra, hogy egyszerre futtasson grafikai és compute futószalagot, de ezt egy multiprocesszoron belül már nem tudta megtenni, így ott vagy az egyik, vagy a másik futhatott. A Pascal ezen a ponton lép némileg előre, ugyanis az NVIDIA lehetővé tesz egy hibrid üzemmódot, amikor egy SMP-n belül az egyik compute blokk grafikai, míg a másik három compute futószalagot futtat. Ez egy szoftveresen, egészen pontosan a felhasználói módban futó eszközillesztőben vezérelt üzemmód, vagyis a meghajtónak az alkalmazás által leadott parancsok alapján fel kell ismernie azt a helyzetet, amikor az SMP-t érdemes hibrid üzemmódba kapcsolni. Az is fontos, hogy ez jó időzítés mellett történjen, ugyanis maga a particionálás statikus és fix időegységre szól, vagyis ha éppen nem tudna a hardver compute futószalagot futtatni, de az SMP-n belüli három compute blokk erre már ki van rendelve, akkor tulajdonképpen az elérhető elméleti teljesítmény háromnegyede elvész, vagyis ezzel a funkcióval nagyon finoman kell majd bánniuk a rendszerprogramozóknak.
A Pascal architektúra túlságosan nem változott a setup területén, a GP104 esetében az NVIDIA továbbra is egy raszteres és egy úgynevezett PolyMorph részre vágja a hagyományos értelemben vett setup motort. Az előbbi egységből négy található a lapkában, azaz egy raszter motor öt darab streaming multiprocesszor ellátásáról gondoskodik. Ezt a felállást a vállalat Graphics Processing Clusternek (GPC) szokta nevezni, és ez most sincs másképp. A raszter motor órajelenként 16 pixelt képes feldolgozni, ami természetesen a teljes lapkára nézve 64 pixelt jelent, és ez tökéletesen egyensúlyban van a 64 blending egységgel is, azaz a friss lapka ezen a ponton kiegyensúlyozott. Mindemellett a GP104 órajelenként négy háromszöget képes feldolgozni.
[+]
A streaming multiprocesszorokban található PolyMorph motor továbbra is a geometriával kapcsolatos munkálatokat végzi, és a korábbi rendszerekhez képest semmit sem változott a működése. Mivel 20 darab SMM található a GP104-ben, így értelemszerűen ez ugyanennyi PolyMorph motort eredményez. Maga a részegység viszont fejlődött, mivel új multiprojekciós motort kapott, amely a Maxwellbe épített opció után már nem csak 9, hanem 16 nézőpozícióba képes továbbítani a geometriát. Ennél fontosabb, hogy lehetővé teszi az egymenetes sztereó 3D-t, vagyis úgy számolható sztereó 3D-s képkocka, hogy a geometriát kettő helyett csak egyszer kell kiszámolni. Ez a virtuális valóság szempontjából további előny.
[+]
A Maxwellhez viszonyítva javult az NVIDIA saját Delta Color Compression technikája, amely még takarékosabban bánik a sávszélességgel. Ezt lényegében két új veszteségmentes tömörítési technika bevezetésével éri el, az eddigi egy mellé.
Multimédia, HDR és API
A GP104 nehezebben emészthető részei után a könnyedebb adatok következnek. Multimédiás fejlesztés, hogy megújul az NVENC nevű hardveres kódoló blokk, amit még anno a Kepler vezetett be; az új rendszer mostantól a H.264-es és a HEVC videók transzkódolása mellett a 10 bites HEVC-vel is megbirkózik. A dekódolásnál is megjelent a 10 és 12 bites HEVC támogatása, illetve VP9 is.
Fontos előrelépés, hogy a Pascal architektúra új kijelzőmotort is kapott, így lehetővé vált a már elérhető HDR kijelzők, illetve az év második felében érkező HDR monitorok támogatása is.
[+]
A GP104-re épülő GeForce GTX 1080 esetében a kijelzőkezelés alapjaiban nem sokat változik, továbbra is maximum négy megjelenítő köthető rá, és az új VGA a szokásos dual-link DVI mellett három DisplayPort 1.2-es aljzatot kínál, illetve marad a HDMI 2.0-s interfész is. Annyit itt is fontos kiemelni, hogy az NVIDIA szerint képesek támogatni a DisplayPort 1.3-as és 1.4-es interfészt is, de konkrét hitelesítés hiányában ezt még nem lehet ráírni a termékekre.
Érdekes extra lesz még a Fast Sync funkció, ami tulajdonképpen egy speciális vertikális szinkron. Működése úgy néz ki, hogy amelyik programban a meghajtóból kényszeríthető a V-Sync, ott a Fast Sync is használható, és ennek segítségével a hardver kizárja a pufferelést. Helyére egy alternatív logika kerül, ami gyakorlatilag mindig csak egyetlen képkockát számol, mégpedig az aktuálisat, ezt elmenti egy memóriaterületre, és a következő kész képkocka is ide kerül. A Fast Sync előnye, hogy a lehető legkisebbre csökkenti a késleltetést, miközben megmaradt a vertikális szinkron által biztosított, képtörésmentes megjelenítés. A technológia ugyan teljesen szoftveres alapokon nyugszik, de használatához Pascal architektúrára épülő grafikus vezérlő szükséges. Mindemellett fontos kiemelni, hogy a rendszert olyan programon belül nem lehet használni, amelyik nem engedi meg a meghajtónak felülírni a beépített vertikális szinkronra szolgáló funkciót; ilyen az összes DirectX 12 és Vulkan API-n futó, illetve az egyes DirectX 10 és 11 API-t használó alkalmazások.
Az API-kra rátérve a Pascal a Maxwellhez képest nem sokat változott, így nagyjából ugyanazokat a DirectX 12 és Vulkan funkciókat támogatja. A DirectX 12 esetében érdemes kiemelni, hogy a Pascal architektúra már támogatja a konzervatív raszterizáció TIER_2-es szintjét. A Maxwell ebből csak a TIER_1-es szintet volt képes használni, de ez a gyakorlatban nem sokat ért, mivel pont az a funkció hiányzik belőle, ami a konzervatív raszterizációnak egyáltalán értelmet ad. Emiatt a konzervatív raszterizációnak a programozók is minimum ezt a szintjét céloznák.
A bekötési modell esetében némiképp csalódás lehet, hogy megmaradt a TIER_2-es szint, vagyis az NVIDIA nem váltott a legjobb TIER_3-asra. Utóbbi azért lenne fontos, mert lehetőséget adna a pure bindless modellre, vagyis a bekötés gyakorlatilag processzorra rót többletterhelés nélkül valósulna meg. Ugyanakkor valószínű, hogy az NVIDIA úgy gondolja, hogy az aktuális DirectX 12-es meghajtóikban mérhető többletterhelés nem annyira kritikus, hogy megérje a hardver nagymértékű áttervezése, ami a TIER_3-as szint eléréséhez szükséges.
Végül az SLI-nek is érdemes egy kis figyelmet szentelni, mivel kiderült pár apró részlet, amely a korábbi híreket más megvilágításba helyezi. Egyrészt az természetesen igaz, hogy az új SLI HB hidakkal csak két GPU támogatott, de opcionálisan használhatók a régi SLI hidak is. Ilyen formában megmarad a három- és négyutas SLI lehetősége is, ugyanakkor elvész a skálázódás 4K-s felbontáson, illetve felette. Az NVIDIA hivatalosan a hagyományos SLI hidakat maximum 2560x1440 pixeles felbontásra és 60 Hz-es frissítésre ajánlja, felette mindenképpen jobb konstrukció az SLI HB.
Ahogy azt egy korábbi cikkünkben leírtuk, a GP104 először csak a GeForce GTX 1080 Founder Edition verzióban lesz elérhető, méghozzá május végén, ára 699 dollár lesz.
Abu85
