Voltába oltott Turing

Az NVIDIA nagyjából egy hónapja jelentette be az új GeForce-ok érkezését, amelyek előrendelhetők is voltak, de a konkrét startra várni kellett, illetve a tesztek is csak később jelenhetnek meg, viszont a hardverek nyers paraméterei bemutathatók. A vállalat három darab lapkát tervezett az új GeForce és Quadro sorozatba, ezek a TU102, TU104 és TU106 kódnevet viselik. Mindegyik a TSMC 12 nm-es FFN node-ján készül, és rendre 18,6, 13,6, illetve 10,6 milliárd tranzisztorból épülnek fel, miközben a kiterjedésük 754, 545 és 445 mm². Ebből látható, hogy a legkisebb is kifejezetten nagy, ezért sincs igazán olcsó verzió, így a korábbi, Pascal architektúrára épülő GeForce-ok a piacon maradnak.

A Turing architektúra leginkább a Volta továbbfejlesztésének tekinthető. A streaming multiprocesszorok általános felépítése az alapvető működést tekintve nem sokat változott, leginkább kiegészült bizonyos képességekkel, illetve az RT maggal, legalábbis ennek egy multiprocesszorra levetített részével. Az ehhez kapcsolódó képességről korábban írtunk, és azóta sincs sokkal több adat, de ugye még nem érkezett meg a Windows 10 új frissítése, ami hozza majd a működéshez szükséges DirectX Raytracinget, így erre később vissza lehet térni. A DLSS-ről sincs sok új információ, ennek a működését is leginkább meg kell nézni a gyakorlatban.

NVIDIA TU102 [+]

A Turing multiprocesszorokon belül marad a négy compute blokk. Ezeken belül marad az egy feladatirányító (dispatch) és az egy warp ütemező, amelyek többféle futószalagot etetnek. Az NVIDIA – szokás szerint – még ma is használja a CUDA mag kifejezést, de ennek a Turing esetében sincs igazán értelme, mivel már nem komplex feldolgozók találhatók a blokkokon belül. Ennek megfelelően a Turing architektúrában – a Voltához hasonlóan – az utasításszavak végrehajtása a nekik megfelelő futószalagon történik. Ha 32 bites lebegőpontos operációról, azaz FP32-ről van szó, akkor egy darab 16 utas, 32 bites integer, azaz INT32 mellett egy darab szintén 16 utas, míg a 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. Alapvető újítás a Volta architektúrához viszonyítva, hogy a Turing képes az INT32 és az FP32 feldolgozók egyszerre történő használatára. Ez igazából egy elméleti képesség, valójában még mindig az határozza meg a gyakorlati használhatóságot, hogy van-e elég szabad regiszter annyira sok warpot futtatni, hogy ezek száma át tudja lapolni a memóriaelérés késleltetését.

[+]

Az NVIDIA CUDA magoknak az FP32-es ALU-kat tartja, ami nem túl kedvező állásfoglalás, hiszen korábban ez egyszerre jelentett lebegőpontos és integer ALU-kat, de ez legyen a legnagyobb probléma. Az FP32 ALU-k az IEEE754-2008-as szabványnak megfelelők, és támogatják a MAD (Multiply-Add), illetve az FMA (Fused Multiply-Add) instrukciókat, valamint 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 load/store egységek bekötése másolja a Volta dizájnját, de változás, hogy ezek száma felére csökkent, változatlanul marad viszont a trigonometrikus és transzcendens utasítások végrehajtásáért felelős speciális funkciókat biztosító egység (SFU). Ez a Pascal architektúrához viszonyítva már nem végez interpolációt, mivel azt a Voltához hasonlóan a Turing is manuálisan oldja meg. Utóbbi egy fontos változás, ugyanis a baricentrikus koordináták kiolvasását már szabványosította a Microsoft a shader modell 6.1-ben, így mindenképpen a manuális interpoláció a nyerő.

A compute blokkokon belüli regiszterterület marad 64 kB, vagyis annyi, amennyi a Voltában volt. A textúrázási képességek területén sincs igazán újítás. Az egyes streaming multiprocesszorok egy darab, négy csatornát biztosító textúrázó blokkot tartalmaznak, amelyet négy compute blokk használ egyszerre.

Végre akcióban az egységes gyorsítótár

Az L1 gyorsítótárat szándékosan hagytuk ki az előző oldalon, mivel itt is a Volta dizájnja köszön vissza, vagyis amíg a Pascal architektúrában az L1 gyorsítótár és a helyi adatmegosztás különálló volt, addig a Turingban ezek egységesek. Ez a struktúra korábban nem volt megtalálható a GeForce-okon, és igazából a Pascal megoldásával sincs akkora baj, de az NVIDIA korábbi architektúráira jellemző volt, hogy tipikusan regiszterszegények, nincs bennük utasítás-előbetöltés, illetve az L1 gyorsítótár elérése is rendkívül lassúnak számított a helyi adatmegosztáshoz viszonyítva, ráadásul a tárkapacitás szempontjából sem voltak eleresztve. Az utasítás-előbetöltés és a regiszterek tekintetében sok választása nincs az NVIDIA-nak. Előbbi eléggé nehezen építhető be egy nem megfelelően kialakított GPU-ba, míg utóbbi igazából elég sok tranzisztort igényel, tehát új gyártástechnológia nélkül ez aligha opció.

Addig nincs is baj, amíg van elég regiszter és helyi adatmegosztás megfelelő számú warpot futtatni, de amint valamelyik elfogy, úgy csökken a futtatható warpok száma, és onnantól kezdve a multiprocesszorok egyre hosszabb ideig várnak majd az adatra. Végül kis számú warpok mellett már az is előfordulhat, hogy a feldolgozókat üresjáratba kell kapcsolni, ugyanis nincs adat, amivel végezhetnék a feladatukat.

Azt tudni kell, hogy a mai GPU-k statikus erőforrás-allokációt használnak, tehát az NVIDIA problémája egyáltalán nem egyedi. Az Intel és az AMD architektúrái is ugyanígy érintettek, csak a konkurensek már korábban elkezdték kezelni a helyzetet. Az Intel például rengeteg regisztert és helyi adatmegosztást épít a fejlesztéseibe, így nagyon nehéz elérni, hogy ezekből kifogyjon a multiprocesszor. Ez amolyan erőből történő megközelítés, aminek az ára a tranzisztorszámon meg is látszik, és az Intel képtelen kellő mennyiségű feldolgozót használni, mert az akkora lapkaterületet igényelne, hogy nem éri meg beépíteni. Az AMD a fenti gondokra először a Polaris architektúrában bevezetett utasítás-előbetöltéssel reagált, amely lerövidíti a memóriaeléréshez szükséges időt, így kevésbé jelent problémát, ha a futtatható wavefrontok száma csökken. A Vega ugyanezt megkapta, és további fejlesztésként az igénybe vehető helyi adatmegosztás kapacitása is nagyobb lett, ami nyilván sokat segít, hiszen innentől kezdve majdnem kétszer több adat fér el benne.

[+]

Az NVIDIA a Volta architektúrában egy másik irányt választott, és ezt örökölte meg a Turing is. Ebben a dizájnban már nincs különálló L1 gyorsítótár és helyi adatmegosztásra szánt memória, hanem ez össze van vonva egy 96 kB-os multiprocesszoronkénti gyorsítótár formájában. A Volta ugye 128 kB-ot használt erre a célra, de kiemelendő, hogy azért valahol kompromisszumot kell kötni a mérnököknek is, hiszen eleve óriásiak az új lapkák, ha nem vesznek vissza a gyorsítótár kapacitásából, akkor még nagyobbak lennének. Idővel visszatérhet a 128 kB-os, vagy akár a nagyobb gyorsítótár, de ahhoz mindenképpen 7 nm-es node-ra kell ugrani.

A strukturális változás következtében L1 gyorsítótár kétszer nagyobb sávszélességgel érhető el a Pascal különálló dizájnjához viszonyítva, illetve a textúra gyorsítótár is megszűnt. Utóbbinak nincs különösebb jelentősége, mivel csak pár kilobájtnyi kapacitásra van szükség, az pedig bőven lecsippenthető a 96 kB-os L1 gyorsítótárból. Maga az összevont L1 gyorsítótár tetszés szerint particionálható. A helyi adatmegosztás kapacitása maximum 64 kB lehet, és a maradék terület maradhat a hagyományos L1 gyorsítótár, ami ezúttal a textúraadatokat is tárolja. Ez a változás két előnyt kínál. Elsődlegesen kevésbé kell a programokat kihegyezni a helyi adatmegosztásra fenntartott adatok manuális menedzselésére, amire egyébként az NVIDIA architektúrája eleve érzékeny. Persze az optimális teljesítmény eléréséhez továbbra is szükség van némi manuális menedzsmentre, de ha ezt kihagyja a fejlesztő, akkor már messze nincs akkora gond, mint a Pascal esetében.

Bár az NVIDIA nem részletezte, hogy az összevont gyorsítótárhoz milyen fordítóoptimalizálást alkalmaznak, de itt hasznos megoldás lehet, ha a shadereket szándékosan limitált, de még relatíve sok warp futtatását lehetővé tevő erőforrás-allokációval fordítják le, és az L1 gyorsítótár elég gyorsan érhető el ahhoz, hogy erre építve a regiszterek felszabadíthatók legyenek. Valószínű egyébként, hogy az NVIDIA továbbra is a helyi adatmegosztásra fenntartott adatok manuális menedzselésére buzdít, az újítás igazából egy könnyítésként szolgál, és ha valakit mondjuk nem különösebben villanyoznak fel a Turing flancos funkciói, az egységes gyorsítótár mindenképpen egy olyan újítás, ami általánosan képes megmutatni az előnyeit. Persze a legtöbb mai alkalmazást még leginkább úgy tervezik, hogy ne nagyon fussanak ki a korábbi hardverek limitjeiből, de idővel a szabványosan előírtnál nagyobb helyi adatmegosztás szükségessé válhat, és erre most már mindhárom PC-s érintett új architektúrái is kellőképpen felkészültek.

A multiprocesszorokon túli felépítés

A Turing architektúra a strukturális felépítést tekintve túlságosan nem változott a setup területén, így 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 három található a TU106-ban, és hat-hat a TU104-ben és TU102-ben. Egy raszter motor egyébként maximum hat darab Texture Processor Cluster (TPC) 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 a TU102 esetében a teljes lapkára nézve 96 pixelt jelent, amely adat egyensúlyban vannak a 96 blending egységgel is, azaz a friss fejlesztés ezen a ponton kiegyensúlyozott. A TU104 esetében is 96 pixellel kell számolni, de ehhez csak 64 blending egység tartozik, vagyis a rendszer ezeket túleteti. Mondjuk ez még mindig jobb opció a TU106-hoz képest, ahol viszont már 48 pixel jut 64 blendingre, azaz ez a konfiguráció kvázi éhezni fog. Mindezek mellett a TU102, a TU104 és a TU106 órajelenként rendre hat, hat és három háromszöget képes feldolgozni.

TU102 [+]

A TPC-kben 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 a TU102-ben, a TU104-ben és a TU106-ban rendre 36, 24 és 18 TPC található, így értelemszerűen ez ugyanennyi PolyMorph motort eredményez.

TU104 [+]

A megosztott L2 gyorsítótár szempontjából a TU102 6, míg a TU104 és TU106 4-4 MB-nyi kapacitást kap. Emellett a GDDR6-os szabványú memóriákat támogató memóriavezérlő szempontjából az NVIDIA maradt a crossbarnál. A TU102 384, míg a TU104 és a TU106 256 bites szélességű buszt használ, ami 32 bites csatornákra van szétosztva. Egy ilyenhez egy ROP-blokk tartozik, amelyen belül 8 bleding és 32 Z mintavételező egység található.

TU106 [+]

Ezek így leírva bonyolultnak tűnhetnek, így az új lapkák elméleti kiépítését az alábbi táblázatban vázoljuk fel:

A friss lapkák közül a TU102 és a TU104 rendelkezik még NVLINK interfésszel is, míg a TU106-ból ez kimaradt. Mivel a korábbi SLI csatlakozót az NVIDIA kivégezte, így két TU106 már nem is köthető össze SLI-be. Ettől még lehet használni két ilyen GPU-t, de ahhoz DirectX 12 és Vulkan API-n futó alkalmazás kell, amelyeknél a több GPU-s támogatása alkalmazásfüggő, így nincs igény a gyártók zárt interfészeinek alkalmazására, hiszen a kommunikáció aszinkron DMA-n keresztül valósulhat meg.

Az NVLINK-et egyébként az NVIDIA nem használja olyan formában, amilyenre egyébként eredetileg fejlesztették, szimplán a korábbi, SLI-hez írt szoftverkörnyezetet portolták rá, vagyis effektíve ez az összeköttetés nem igazán több a korábbi megoldásnál. Lehetőség amúgy lenne benne, elvégre memóriakoherens interfészről beszélünk, de valószínűleg az NVIDIA nem különösebben akar erre pénzt áldozni, hiszen a DirectX 12 és Vulkan API-n belül az aszinkron DMA-n keresztüli kommunikáció van definiálva, ami úgyis a PCI Express interfészen keresztül zajlik.

A Turing extrái

A hardverek kivesézése után maradt még pár olyan újítás, aminek megéri szót szentelni. Egyrészt a Turing architektúra továbbfejlesztett veszteségmentes tömörítési eljárást kapott a Pascalhoz viszonyítva, ami az NVIDIA szerint 50%-kal hatékonyabb.

Variable Rate Shading [+]

A virtuális valóságot is célozza pár fejlesztés. Az egyik ilyen a Variable Rate Shading (VRS), ami gyakorlatilag lehetővé teszi, hogy az árnyalás ne a teljes felbontáson történjen meg. Ennek alapvetően tényleg a virtuális valóság a legfőbb célpiaca, hiszen például foveated rendering mellett elég csak a szem fókuszpontjában található részleteket teljes felbontáson számolni. Ilyet a mai hardverekkel is lehet már csinálni, a Turing újítása igazából a tartalomhoz igazodó árnyalás. Ebben a módban az adott szoftver utasíthatja a hardvert, hogy bizonyos pixelblokkokra ne alkalmazzon teljes részletességű számítást, hanem valamilyen kisebb részletességű minta alapján dolgozzon. Ez természetesen a grafikai minőség csökkenésével is jár, de megfelelően kialakított konfiguráció mellett ez nehezen észrevehető.

Multi-View Rendering [+]

A másik virtuális valóságra koncentráló újítás a Multi-View Rendering (MVR), amit ma még nem igazán lehet használni, mivel megfelelő VR-headset is szükséges hozzá. A lényege ugyanakkor annyi lenne, hogy a mai megoldásokkal ellentétben nem csak két, hanem négy nézőpontra is levetíti az adott jelenetet, ami kedvezőbb a széles látószögű headsetek számára. Ez persze teljesítményvesztéssel is jár, hiszen ilyenkor már nem csak sztereó képet kell számolni, hanem mellé még két képkockát, de igazából erre a funkcióra még megfelelő headset sincs, tehát ez nem egy mának fejlesztett technika.

Szintén érdekes a Texture-Space Sharing (TSS), ami igazából nem mondható akkora újításnak, hiszen gyakorlatilag a texel shading egy eleméről van szó, és már létezik olyan videojáték-motor, ami hasonló leképezőt használ. Itt igazából arról van szó, hogy Turing az efféle leképezők igényeihez jobban igazodik, mint a korábbi Pascal, így el lehet érni olyan optimalizálási lehetőségeket, amelyek az előző generációs GeForce-okban nem voltak jelen. Ettől persze még számos korábbi GeForce képes alkalmazni a texel shadinget, csak a Turing valamivel gyorsabban teszi ezt.

Végül megjelenik egy úgynevezett mesh shading is, ami valójában a vertex és a hull shadert váltja le a task shaderrel, míg a mesh shader a domain és a geometry shader lépcsőket helyettesíti. Gyakorlatilag egy új futószalagról van szó. Nem lehet elmenni amellett szó nélkül, hogy eléggé sok a hasonlóság az AMD Vega architektúrában bemutatott primitive shadinggel, ahol ugye a vertex és a hull shader lépcsőket a surface shader váltja, míg a primitive shader a domain és a geometry shader helyére kerül, illetve a leírások alapján is hasonlóra képesek az említett futószalaglépcsők, vagyis próbálják a geometria kivágását, illetve ezek kezelését hatékonyabbá tenni.

[+]

A mesh shading ugyanúgy kihasználhatatlan a jelenlegi formájában, ahogy a primitive shading, de tekintve, hogy két gyártó is ilyen irányba lépked, valószínűnek tartjuk, hogy a háttérben a Microsoft és a Khronos Group már elkezdte kialakítani a következő generációs raszterizációs futószalagot, ahol az igen elavultnak tekinthető, geometria feldolgozásáért felelős rész leváltásra kerül.

Azt nem igazán tudni, hogy ebből mikor lesz valami. Az NVIDIA is az AMD-hez hasonló helyzetben van, vagyis az aktuális API-k nem engedik a grafikus futószalag módosítását, így nagyon nehéz egy játékba beműteni ezeket az újításokat. Egy részét talán át lehet menteni compute shaderbe, ahogy az AMD is megtette ezt a Wolfenstein 2: The New Colossus című játék esetében, de ez nem igazi megoldás. A komolyabb előrelépéshez meg kell várni, amíg azok az API-k megérkeznek, amelyek már támogatják az új futószalaglépcsőket.

A Turing és a multimédia

A Turing nehezen emészthető részei után végre jöhetnek a könnyedebb adatok. 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 8K-s, 30 fps-es HEVC videók kódolásával is megbirkózik. A dekódolásnál megjelent a 10 és 12 bites VP9 kezelése, illetve a 10 és 12 bites HEVC esetében a 4:4:4-es formátum.

A kijelzőmotor újítása a DisplayPort 1.4a támogatása a DSC 1.2-vel, így megoldható a 8K-s 60 Hz-es kijelzők meghajtása. A HDMI tekintetében marad a 2.0b-s port, vagyis a sokak által várt HDMI VRR, azaz a HDMI Forum szabványos variálható frissítési frekvenciája nem lesz elérhető. Mindezek mellett a VirtualLink támogatása is megjelenik, de ezt nem kötelező használni a partnerek számára.

[+]

Végül szoftveres szinten némileg változik a tuning is, ugyanis az NVIDIA kiegészíti az NVAPI-t, az új NV Scanner API-val. Ezt a tuningszoftvereket fejlesztők építhetik be, és lényegében arról van szó, hogy egy "szkenner" funkció automatikusan megpróbálja megkeresni a legmagasabb stabil órajeleket.

Természetesen a tuningra továbbra sem lesz garancia, és az is előfordulhat, hogy a "szkenner" használatakor lefagy a PC. A lényeg itt igazából az egyszerűsítés, ami az újítással meg is történik.

Ahogy azt a korábbi hírben leírtuk a TU102-re, TU104-re és TU106-ra rendre a GeForce RTX 2080 Ti, 2080 és 2070 épül. A hardverek hamarosan megvásárolhatók lesznek, de a tesztekre még várni kell, ugyanis ezekre vonatkozóan még nem járt le az embargó.

Abu85