A trükkösen duplázó Ampere

Régóta vár már a piac az új VGA-generációra, és az NVIDIA a hónap elején jelentette be az új GeForce-ok érkezését, amelyek közül az RTX 3080 jelölésű modell elérhetővé is vált. Ez a fejlesztés nem a sorozat leggyorsabbika, de mondhatni még éppen megfizethető áron kínál nagy teljesítményt.

Az alapokat tekintve az NVIDIA a Turing helyére az Ampere architektúrát dobta be, amely az említett VGA esetében a GA102 kódnevet viselő lapkában fog dolgozni. A fejlesztés a Samsung 8 nm-es node-ján készül, és 28,3 milliárd tranzisztorból épül fel, miközben a kiterjedése 628,4 mm². Látható, hogy nem kis GPU-ról van szó, de ha az elmúlt évek generációit nézzük, akkor ezt az NVIDIA-tól már megszokhattuk.

Az Ampere architektúra elsődlegesen a Turing kigyúrásának tekinthető. A streaming multiprocesszorok általános felépítése sok szempontból hasonló, de azért vannak trükkös változások is. Olyan dolgokhoz tér vissza az NVIDIA, amelyeket a G80 megjelenése, vagyis effektíve a 2006-os esztendő előtti időkben alkalmaztak, ráadásul ezekben a nagyon rég elfeledett ötletekben még van is ráció – de nézzük inkább a részleteket!

Az Ampere architektúra multiprocesszora [+]

Az Ampere multiprocesszorokon belül marad a jól megszokott, négy compute blokk. Ezekben található egy L0 utasítás gyorsítótár, egy feladatirányító (dispatch), illetve egy warp ütemező, amelyek többféle futószalagot etetnek. Az NVIDIA természetesen továbbra is használja a CUDA mag kifejezést, de ahogy korábban, úgy ennek az Ampere esetében sincs értelme, mivel már nem komplex feldolgozók találhatók a blokkokon belül. Ennek megfelelően az Ampere architektúrában – a Turinghoz 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 256 utas, structural sparsity támogatással dolgozó tömb áll rendelkezésre. Utóbbi esetben fontos kiemelni, hogy ezek strukturálva vannak, vagyis egy 256 utas tömb gyakorlatilag két darab úgynevezett tensor magot jelent, amelyek 128-128 darab ALU-t használnak.

A dizájn alapjai ismerősek lehetnek, de az NVIDIA bedobott egy trükköt, ugyanis amíg a 16 utas FP32 feldolgozótömb változatlan, addig az INT32-es opció kiegészült olyan formában, hogy már 32 bites lebegőpontos operációkat is képes végrehajtani. Az új rendszerben tehát egy compute blokkon belül akár két darab 16 utas FP32 feldolgozótömb is befogható, vagyis egyszerre két darab olyan warp (megszokott szóhasználattal élve wave) is futtatható, amelyekben 32 bites lebegőpontos operációk kerülnek végrehajtásra. Ezzel az NVIDIA ismét bevezeti a co-issue feldolgozási modellt, méghozzá 16+16-os formában, vagyis ideális körülmények fennállása esetén egy compute blokk 32 bites lebegőpontos számítási teljesítménye a Turinghoz képest megduplázódik. A kérdés az, hogy mi az ideális körülmény.

Elsődlegesen a két futtatott warp egy ütemezőn kerül kiosztásra, vagyis a feldolgozandó feladatok között nem állhat fenn függőség. Ez a legfontosabb kritérium. Ha az ütemező a compute blokkon belül nem tud kiosztani két olyan warpot, amelyek nem függnek egymástól, akkor csak az alapértelmezett FP32 feldolgozótömb fog működni. Szintén lényeges, hogy ne legyen INT32 feladat sem, ugyanis ebben az esetben muszáj lekötni az INT32 operációkat kezelő feldolgozótömböt, amely értelemszerűen így nem tud FP32-es operációkat elvégezni. Ezekben az esetekben az elméletileg beépített FP32-es számítási kapacitás fele érhető el.

Az NVIDIA egyébként továbbra is az FP32-es ALU-kat tartja CUDA magoknak, és ezek a részegységek megfelelnek az IEEE754-2008-as szabványnak, vagyis támogatják a MAD (Multiply-Add), illetve az FMA (Fused Multiply-Add) instrukciókat. Az FP16-os műveleteket az alapértelmezett feldolgozótömb kezeli, 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 másodlagos, INT32-es feldolgozótömb ugyan az FP32-t támogatja, de az FP16-ot már nem, tehát az Ampere esetében a szimpla és a felezett pontosság melletti elméleti számítási teljesítmény megegyezik, ellentétben a Turing dizájnjával, ahol utóbbi duplája volt az előbbinek. Itt megjegyzendő, hogy az új architektúra támogatja a bfloat16 adattípust is, ami a gépi tanulás tréning szakaszánál lehet hasznos. Ennek az az előnye, hogy a 32 bites lebegőpontos adattípussal megegyezően 8 bites exponenst használ, viszont a mantissza 23 bit helyett csak 7 bites. Ezzel természetesen a pontosság csökken, de a célterületet tekintve így is kedvezőbb a normál 16 bites lebegőpontos (FP16) adattípushoz viszonyítva.

A load/store egységek bekötése gyakorlatilag a Turing dizájnját másolja, ahogy a trigonometrikus és transzcendens utasítások végrehajtásáért felelős speciális funkciókat biztosító egység (SFU) kialakítása is. 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.

A compute blokkokon belüli regiszterterület marad 64 kB, vagyis annyi, amennyi a Voltában és a Turingban volt. Ez abból a szempontból nem túl szerencsés, hogy az FP32 feldolgozók megduplázódtak a compute blokkon belül, miközben az adatokat annyi helyen kell tárolni, mint amennyit az előző két generáció architektúrája kínált. Ha esetleg olyan shadert fog futtatni a compute blokk, amelynek igen nagy a regiszternyomása, akkor nem biztos, hogy befogható a második 16 utas FP32 feldolgozótömb, vagyis egy fog működni. Az úgynevezett LDS-nyomás hasonlóan probléma lehet compute shaderek esetében, de ritkábban, mivel az Ampere-en belül az NVIDIA átalakította az L1 gyorsítótár működését. Egyrészt a sávszélességét megduplázták 64-ről 128 bájt/ciklusra, másrészt 96-ról 128 kB-ra nőtt a kapacitása. Utóbbi több konfigurációban fogható be. Amennyiben az adott compute blokk grafikai feladatot futtat, akkor kötelező 64 kB-ot biztosítani a textúrázóegységeknek, illetve az egyéb adatok tárolására, 48 kB lesz a helyi adatmegosztás, illetve 16 kB fenntartása szükséges a grafikai futószalagokhoz. Compute feladatok mellett már sokkal szabadabb a felhasználás, az általános gyorsítótár 28, 64, 96, 112, 120 vagy 128 kB lehet, az éppen aktuális maradék pedig felhasználható helyi adatmegosztásra.

Kétségtelen, hogy az új generáció multiprocesszorában található compute blokkok elég bonyolultan működnek ahhoz képest, amit mondjuk a Turing esetében megszokhattunk. A legnagyobb és egyben legfurcsább fejlesztés a 16+16 co-issue feldolgozási modell, amire azért állhatott át az NVIDIA, mert a Turing dizájnjában már eleve ott csücsült a 16 utas INT32 feldolgozótömb, és azt nem túl nagy tranzisztorköltség kiegészíteni FP32 operációk támogatásával. Még ha nem is tud mindig működni a feldolgozók egyik fele, akkor is megérhette, mert a tipikus teljesítményelőny, amit a gyakorlatban hoz, nagyobb lehet, mint amennyi tranzisztor beépítését igényelte. Erre természetesen lehet optimalizálni a programkódban is, sőt kifejezetten ajánlott, mert az Ampere teljesítménye a korábbi generációkhoz viszonyítva jobban függ majd a futtatott shaderektől.

A multiprocesszorokon túl

Az Ampere architektúra strukturális felépítésében 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ét található a GA102-ben, és egy raszter motor 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 GA102 esetében a teljes lapkára nézve 112 pixelt jelent, amely adat egyensúlyban van a 112 blending egységgel is, azaz a friss fejlesztés ezen a ponton kiegyensúlyozott.

NVIDIA GA102 [+]

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 GA102-ben 42 TPC található, értelemszerűen ez ugyanennyi PolyMorph motort eredményez.

Ahol változás történt, azok a ROP-blokkok, ezek képességei ugyan nem módosultak, tehát továbbra is 8 blending és 32 Z mintavételező egység található bennük, viszont beköltöztek a GPC-be, méghozzá párosával, így egy ilyen nagyobb feldolgozótömb két ROP-blokkot kínál.

A GA102 10 752 kB megosztott L2 gyorsítótárat kap, és ehhez kapcsolódik mostantól a GDDR6X-os szabványú memóriákat támogató memóriavezérlő, ami a GA102 esetében 32 bites csatornákra szétosztott, 384 bites buszt eredményez. Ráadásul a lapka rendelkezik még négy darab NVLink interfésszel, két DMA motorral, emellett beveti a PCI Express 4.0 támogatását.

Végre itt az SR-IOV!

Az Ampere egyik kevésbé reklámozott, de amúgy jelentős újítása a PCI-SIG SR-IOV (single root I/O virtualization) szabványára épülő virtualizáció támogatása. Ennek a GeForce termékskálán ugyan nincs jelentősége, mert az NVIDIA nem fogja a meghajtóban kihasználhatóvá tenni, de a professzionális modelleken nyilván elérhető lesz.

De miről is van szó? A GPU-s virtualizáció terén az NVIDIA korábban saját szoftveres megoldását erőltette, amely a GPU-s munkaasztalra vonatkozó virtualizációs forma szempontjából függetlenített időosztásos modellben tette elérhetővé a multiprocesszorokat, illetve a videodekódoló és -kódoló blokkot, míg a videomemóriát szimplán fizikai felosztásúként lehetett használni. Ennek az előnye, hogy szoftveres Hypervisor menedzsmenttel viszonylag egyszerű volt a korlátozott képességű hardverekre is biztosítani magát a virtualizációt, de számos limitációt generált, amelyek közül a legnagyobb az volt, hogy a videomemóriát nem védte semmi, ami miatt relatíve egyszerűen kivitelezhetővé vált az, hogy az egyik GPU-s munkaasztal tartalmát kimásolja egy másik, ezzel pedig az adatlopás kockázata nem zárható ki.

A Hypervisor menedzsment azonban már régóta létezik hardveres (SR-IOV) formában, például az AMD évek óta ezt alkalmazza, és az előnyök világosak, hiszen a videomemória védett fizikai felosztásúvá válik, ahogy maga GPU is, tehát egy virtualizált környezet fix erőforrásokat kap az adott lapkán belül, és ezeket más kliensről nem lehet elérni, vagyis az adatlopás lényegében kizárt.

Az NVIDIA technológiája kapcsán annyi biztos, hogy a multiprocesszorok elérhetők fizikai felosztás szintjén, de a videodekódoló és -kódoló blokkal kapcsolatban nincs adat a virtualizáció formájáról, ugyanakkor valószínűleg itt is történt némi előrelépés.

Az Ampere esetében ez főleg a felhős játékszolgáltatások terén lesz hasznos, ugyanis ilyen formában nem csak a GeForce Now rendszerén belül tudja majd használni termékeit a cég, hanem a hardveres virtualizáció miatt már a többi platform tulajdonosa is elgondolkodhat rajtuk, nem lesznek az AMD megoldásaira kényszerítve.

Sugárkövetés jobban

A sugárkövetést az előző oldalakon szándékosan hagytuk ki, ugyanis kicsit bővebb magyarázatot érdemel, hogy mi változott. Az NVIDIA úgynevezett RT magként jelzi az eljárásért felelő egységeket, és ezekből egy-egy feldolgozó található multiprocesszoronként, azaz a GA102 lapkára nézve 84. A valóságban azért ez bonyolultabb, hiszen ezeknek az RT magoknak van vezérlőjük, és a működésük is teljes lapkára levetítve értelmezhető igazán. Emiatt fontosnak tartjuk leírni, hogy amikor egy RT magról beszélünk, akkor valójában a sugárkövetés feladatának egy részét tárgyaljuk, méghozzá a metszésvizsgálatot, illetve a bejárást.

De nem csak a hardverről van szó, ugyanis a Microsoft szoftveres szempontból is jelentős változásokat eszközöl. Az első DirectX Raytracing a bemutatásakor – nevezzük DXR 1.0-nak, mert már az érintettek is ezt teszik – egy úgynevezett dynamic shader based raytracinget kínált fel. Ez leginkább annyit tudott, hogy működött, de egyáltalán nem a teljesítményre volt optimalizálva. A rendszer alapvetően annyit tett, hogy kilőtte a sugarakat, a hardver megkereste, hogy hol talál el például egy háromszöget, ha egyáltalán lesz találat, és ennek megfelelően jöhetett egy hit (találat esetén) vagy miss (találat nélkül) shader. Bármelyiket is hívta meg a program, az be lett linkelve az erre vonatkozó bekötési táblába, és ez alapján tudta a rendszer megosztani a hit vagy miss shaderrel a szükséges adatokat, vagyis ilyen formában volt végigkövetve egy sugár útja.

Az új DirectX Raytracing, rövidebb nevén DXR 1.1 a fentiekkel szemben bevezeti az úgynevezett inline raytracinget. Ez alapvető váltás a korábbi módszerhez képest, mivel megszűnik a bekötési tábla, illetve nem lesz több elszeparált dinamikus shader. Ehelyett már az eredeti shader tartalmazza a kontextus struktúráját, és utasítja a hardvert, hogy kezdje meg a bejárási lépcsőt. Ha egy sugárnak lesz találata, akkor a függvény visszatér, és már eleve ott van a kontextus struktúrája a shaderben, amivel rögtön megkezdődhet a munka, nem kell már semmiféle adatmozgás, illetve elszeparált dinamikus shader indítása ehhez.

Szoftveres szinten ez igen jelentős különbség, és például az inline raytracing azért feltételezi, hogy a hardver ütemezője képes végigkövetni a sugár útját. Ha nem, akkor erre valamiféle emulációt kell írni, ami a program oldalán láthatatlan formában ugyan, de annak ellenére is visszahozza a bekötési táblát, hogy maga a friss futószalag kivonta azt.

Az NVIDIA ennek a hardveres implementációjáról olyan sokat nem árul el. Az világos, hogy a Turing a dynamic shader based raytracingre volt tervezve, hiszen akkor még úgy tűnt, hogy ez lesz a jó irány, csak azóta a Microsoft meggondolta magát, és hoztak egy alternatív megoldást. Arról nincs pontos adat, hogy az Ampere erre mennyire van felkészítve, valószínű ugyanakkor, hogy az ütemezés fejlődött annyira, hogy az inline raytracingre optimális legyen a hardver.

Ha az ütemezést figyelmen kívül hagyjuk, akkor bármilyen sugárkövetést biztosító megoldást is veszünk, az adatmozgás tekintetében a hardveres megvalósítások egy kaptafára épülnek. Effektíve az adatok biztosítása során kvázi ugyanaz történik. Részletesebben leírva, a geometriára vonatkozó árnyalási fázisokat követően egy jelenet hierarchiáját generáló részegység készít egy BVH (bounding volume hierarchy) gyorsítóstruktúrát. Ennek egy része statikus, vagyis újrahasznosítható, de az animációk miatt szükség van dinamikus, azaz jelenetenként frissülő adatokra is. Tulajdonképpen ez az alap, az egész működés kiindulási pontja, ugyanis eléggé fontos, hogy a hardver az egyes sugarak tesztelésekor ne menjen végig az jelenetben található összes háromszögön, mivel az eléggé lassú lenne. Ezeket inkább csúnyán fogalmazva bedobozolja, és a sugárnál így elég azt tesztelni, hogy eltalálja-e az adott dobozt. Valamelyiket el fogja, és ilyenkor elég csak azokra a háromszögekre koncentrálni, amelyek az adott dobozon belül vannak. Persze részletes geometria mellett nem árt többszintű struktúrát alkalmazni, ami – ismét csúnyán fogalmazva – dobozokat jelent majd a dobozban. A végeredmény szempontjából az a lényeg, hogy kellően mély legyen az adott BVH gyorsítóstruktúra, aminek hála ugyan hat-hét dobozon talán át kell menni, de végül csupán pár vagy pár tucat háromszögre kell tesztelni az adott sugarat. Ez pedig még mindig gyorsabb, mintha erőből csinálnánk mindent.

Az RT magokon belül a fenti folyamat gyorsítására való, metszésvizsgálatra, illetve bejárásra vonatkozó részegységek tanyáznak. Nagyon leegyszerűsítve utóbbi azt segíti, hogy a kamerából koherensen kilőtt sugarak a meghatározott távolságig teljesen bejárják a jelenetet, előbbinek hála pedig vizsgálva lesz, hogy mibe ütköznek bele.

A Turing és az Ampere RT magja [+]

Az NVIDIA az Ampere esetében két változással élt a szóban forgó RT magok kapcsán. Többek között a háromszögekre vonatkozó metszésvizsgálat kétszer gyorsabb lett, ami jó hír, mert a Turing itt nem volt valami combos, továbbá van egy új részegység, ami képes az idő függvényében interpolálni az adott háromszög pozícióját. Utóbbival a mozgás irányú elmosás (motion blur) effektet lehet hardveresen gyorsítani.

Van még egy újítás, de az nem tartozik szorosan az RT magokhoz. Ahogy korábban már leírtuk, ez az egység csak a teljes eljárás egy részéért felel, de még a sugárkövetés is igényli az általános feldolgozókat (nagyon is), tehát vannak olyan feladatrészek, amelyek multiprocesszorok compute blokkjainak futnak le. Ezek a Turing esetében elvették a szabad számítási kapacitást a grafikai munkától, de az Ampere-nél, az első oldalon már részletezett, másodlagos, INT32-es feldolgozótömb FP32-es támogatásának hála nem fogják túráztatni az alapértelmezett feldolgozókat. Ez a konkurens végrehajtási forma némileg gyorsítani tud egy-egy sugárkövetéssel számolt effekt futtatásán. Ez a funkció azonban nem igazán működik automatikusan, az alkalmazásokat fel kell készíteni rá, hasonló módon, ahogy például az aszinkron compute-ot szokás alkalmazni.

Az Ampere és a multimédia, plusz a szoftverek

Az Ampere multimédiás szinten is fejlődött, megújul az NVDEC nevű hardveres dekódoló blokk, ami kezeli az AV1-es, 8 vagy 10 bites, akár 8K-s, 60 Hz-es, 4:2:0-s formátumú videókat. A kódolásért felelős NVENC változatlan maradt, így a Turingba épített verziót viszi tovább az NVIDIA.

[+]

A kijelzőmotor megörökölte az előző generációból a DisplayPort 1.4a támogatását a DSC 1.2-vel, újítás viszont a HDMI 2.1, vagyis ezen keresztül is megoldható a 8K-s 60 Hz-es kijelzők meghajtása. A vállalat a VirtualLink támogatását elengedte, a partnereknek viszont nincs megtiltva ez az interfész, ha hasznosnak vélik.

Az NVIDIA a szoftveres háttéren is újít, ráadásul nem csak Ampere architektúrán működő fejlesztésekkel, így érkezik a Reflex, amiről korábbi hírünkben már bővebben írtunk, illetve lényeges még az RTX IO. Utóbbi minden GeForce RTX sorozatú kártyán elérhető lesz, hiszen hardveres szinten a compute shaderre, két DMA motorra, illetve egy régóta elérhető technológiára, az NVIDIA GPUDirectre épít. Utóbbi biztosítja a direkt memóriamásolást a PCI Express eszközök között.

Az RTX IO nem más amúgy, mint egy implementáció a DirectStorage API-ra, amelyet a Microsoft nemrég jelentett be PC-re. Ennek előnyeiről, illetve hátrányairől is írtunk már egy korábbi hírünkben.

A DLSS kapcsán az NVIDIA beveti a 2.1-es verziót, amelynek a fő előnye, hogy engedélyezi a technológia alkalmazását a VR headseteken belül, illetve lehetővé teszi a 8K-ra való felskálázást. Ezek leginkább beállításbeli kérdések, tehát az alapvető technológia tekintetében nem igényelnek drámai újítást.

Kiemelnénk, hogy az előbbiekben a GA102-es lapkáról beszéltünk, olyan formában, amilyen maga a GPU, viszont a tényleges VGA-kon a fejlesztés bizonyos részegységek letiltásával lesz elérhető, így kevesebb feldolgozó áll majd rendelkezése, függően attól, hogy az adott grafikus kártya GeForce RTX 3080 vagy 3090. Ezek konkrét specifikációit szintén egy korábbi hírünkben ismertettük.

Versenytársak, tesztkörnyezet

Tesztkonfiguráció, szoftverek

Mielőtt rátérnénk az eredményekre (hé, tilos lapozni!), muszáj ismertetni a tesztkörnyezetet, mely alaposan megváltozott az utolsó dedikált videokártyateszt óta. Az új platform egyrészt gyorsabb memóriát kapott, másrészt lehetővé teszi a PCIe 4.0 kínálta sávszélesség kihasználását (legalábbis adattároló frontján).

A hardveren kívül a mérésekhez használt szoftvercsomagot is módosítottuk némileg (az operációs rendszer frissítése mellett), és ami ennél is fontosabb, ahogy a Z490-es ASUS ROG Maximus XII Hero tesztjében is említettük, a játékoknál teljes mértékben áttértünk az OCAT 1.6/FrameView 1.1 használatára. Ez azt jelenti, hogy a beépített benchmarkok végén kiírt számok helyett az említett szoftver(ek) mérte időkből számoljuk a képkocka/másodperc értékeket. Ezeknél szokás szerint az alsó és felső 5 százalékot elhagyjuk, így az esetleges véletlenszerű megtorpanások nem befolyásolják az eredményt, melyet a háromszori mérésből végzett átlagolás is pontosít.

A használt szoftverek és beállításaik jelen pillanatban a következők:

Versenyzők

[+]

Az új tesztkörnyezet és metodika kellemetlen következménye (azon túl, hogy sokat kell az Excelt használni), hogy korábbi eredményeink nem használhatók fel. Mivel a váltás csak most történt, a régebbi kártyák újramérése még nem fejeződött be, így az RTX 3080 mellé egyedül a korábban már bemutatott Gigabyte AORUS 2080 Ti Extreme szállt versenybe. Ahogy hamarosan látni fogjuk, ez nem akkora gond, mint elsőre tűnik.

[+]

Az AORUS 2080 Ti Extreme egy gyárilag alaposan túlhajtott modell, 1770 MHz-es boost órajellel, de versenytársa, az ASUS TUF Gaming GeForce RTX 3080 OC is tuningolt verzió, 1815 MHz-es boost frekvenciával, így teljesen fair a küzdelem. Az RTX 3080 mellé 10 GB GDDR6X RAM-ot kapunk, mely 19 Gbps sávszélességgel rendelkezik, a kimenetek száma pedig öt: három DisplayPort és két HDMI 2.1 csatlakozó áll rendelkezésre.

[+]

Az ASUS kártyája a normál RTX 3080-hoz képest egy alaposan átdolgozott modell, és ennek az átdolgozásnak az egyik előnye, hogy nem igényel újfajta tápcsatlakozót, nyugodtan használhatjuk a megszokott 2x 6+2 tűs rendszert. A robosztus, 2,7 slotos (300 x 127 x 52 mm-es) kártyán három ventilátorral dolgozó hűtés van, mely az NVIDIA ajánlásának megfelelően túllóg az áramköri lapon, a leghátsó ventilátor így a kártya alatt megrekedő meleg levegőt gyakorlatilag átfújja a másik oldalra, jelentősen javítva a hűtést.

[+]

Az átdolgozott, a korábbinál minimálisan hangosabb, de erősebb légkavarók közül a középső jobbra, a két szélső pedig balra forog, maximális fordulatszámuk 3600 rpm, de 55 Celsius-fokos GPU-hőmérséklet alatt passzív üzemmódra váltanak. Alattuk átdolgozott, a korábbi ROG Strixes változnál 15%-kal nagyobb hőleadó felületű bordázatot találunk, mely külön egységgel hűti a memóriamodulokat. Mint az a TUF modelleknél megszokott, a komponensek kiválasztásakor és a tesztelések során extra figyelemet szenteltek a strapabíróságnak.

[+]

A kártyáról nem hiányzik természetesen némi RGB sem, a ventilátorok feletti részen látható TUF logó színét az Armoury Crate-en keresztül tudjuk szinkronba hozni a többi komponenssel. A kártya alumíniumlemezzel burkolt hátoldalán szokás szerint egy apró kapcsolót is találunk, mely a teljesítmény- és csendcentrikus beállítások közötti váltást teszi lehetővé (mi az előbbit használtuk a teszt során).

A tesztben résztvevő versenyzők fontosabb tulajdonságai a következők:

Eredmények

Röviden összefoglalva a látottakat, azt mondhatjuk, hogy az NVIDIA mérnökei nem grillezéssel töltötték az elmúlt két évet, az Ampere – legalábbis az RTX 3080 alapján – simán lekörözi a Turingot. Az újdonság fölénye magasabb felbontásokban egyértelmű, az UHD beállításnál 20-30%-os gyorsulást is láthatunk. A pixelszám csökkentésével persze a CPU-limit is elkezdi felütni a fejét az erre hajlamos játékoknál (Deus Ex, Forza Horizon 4, Shadow of the Tomb Raider), de például a Strange Brigade egyszerűen csak tovább száguld olyan számokkal, melyek a frissen érkező 360 Hz-es monitorokat is megdolgoztatják.

Ami biztos, hogy a nem kompetitív játékosok számára tulajdonképpen minden téren elérkezett a 4K korszaka: gyakorlatilag nincs olyan játék a piacon, amit ne lehetne az RTX 3080-nal kényelmesen futtatni ezen a felbontáson, maximális, vagy esetleg kicsit az alatti minőségi beállítások mellett.

Sugárkövetés hatása, fogyasztás, hőmérséklet

A sugárkövetéssel kapcsolatos fejlesztésekről már írtunk a 3. oldalon, itt a teljesítményre gyakorolt hatását vizsgáltuk. Legyünk őszinték: az eredmények nem igazán látványosak, felbontástól és programtól függően 20-40% körüli visszaeséssel is számolhatunk (a tesztekben az „Ultra” beállítást használtuk). Bár ez valamivel kevesebb, mint az RTX 2080 Ti-nél, a különbség nem jelentős, de ez a szoftveres fejlesztésekkel még változhat, ahogy a programok jobban kihasználják majd az Ampere újdonságait.

Ne feledkezzünk meg persze arról sem, hogy az RTX 3080 eleve magasabb szintről indul, ahonnan némileg kisebb arányú visszaesés után QHD felbontásban még mindig bőven játszható marad a program.

Fogyasztás és hőmérséklet.

A 8 nm-es node elvileg alacsonyabb fogyasztást ígérne, de az RTX 3080 jobban pörög az RTX 2080 Ti-nél, így a végső eredmény az, hogy rendszerünk több energiát igényel a konnektorból. Az NVIDIA hivatalos ajánlása szerint a tesztelt kártyához 750 wattos tápegység dukál – tesztágyunk mérései alapján azért ennél kisebb modellel is használható az RTX 3080, feltéve, ha az tényleg jó minőségű. Mindenesetre az 500 wattos szegmenssel valóban nem érdemes próbálkozni.

Amennyiben közelebbről is megvizsgáljuk a Forza Horizon 4 futtatása során kapott értékeket, látszik, hogy az új GPU valóban kevesebbet fogyaszt a korábbi csúcsmodellnél – a teljes kártya viszont mégis több energiát igényel. Az ASUS hűtése viszont kiválóan vizsgázott, körülbelül 10 °C-os előnyben van az RTX 3080 OC a Gigabyte AORUS 2080 Ti-jével szemben.

Értékelés

Nehéz mást mondani, mint hogy az RTX 2080 Ti gyakorlatilag halott: az RTX 3080 gyorsabb és olcsóbb, ráadásul az energiával is jobban gazdálkodik valamivel, az előző generációs csúcsmodell tehát elvesztette minden előnyét. A boltokban a 2080 Ti kártyák ára körülbelül 410-420 000 forintról indul (a tesztben szereplő modell ennél jóval gyorsabb), míg az ASUS TUF Gaming GeForce RTX 3080 OC ajánlott ára 318 500 forint, de a ROG Strix változatot is 360 000 forint alá szánják (az RTX 3090 persze más tészta, az 650 000 forintos árszinten érkezik). Ami az elérhetőséget illeti, a tervek szerint szeptember végére már biztos itt vannak az előrendelt példányok.

Ugyan a csúcskategóriában csak kevesebb értelme van ár/értékről beszélni, azt megjegyeznénk, hogy az RTX 3080 ezen a téren inkább az RTX 2080 Superrel mérkőzik: az utóbbi persze átlagosan körülbelül 40-50%-kal lehet lassabb nála, viszont 230-240 000 forintért megvásárolhatjuk. Mi mondjuk nem tennénk, inkább megvárnánk az RTX 3070 érkezését.

Visszatérve most magára az RTX 3080-ra, csak ismételni tudjuk, hogy az NVIDIA tervezői remek munkát végeztek, az Ampere szinte minden területen jelentős előrelépés a Turinghoz képest. Az új GPU-val így tényleg beléptünk a 4K gaming világába, a Full HD felbontásnak csak kompetitív környezetben maradt értelme. Tulajdonképpen ezúttal még az árazással sincs komoly probléma, igaz, ebben az elmúlt években elszállt videokártya-áraknak is benne van a keze.

[+]

Az ASUS konkrét termékét nézve sem panaszkodhatunk, a TUF Gaming GeForce RTX 3080 OC egy igényes, masszív kártya, nagyon jó tudású hűtéssel. Az optikai „bling” hiányzik róla, de ezt cégen belül meghagyják a ROG Strix változatoknak, ezért cserébe viszont pár tízezer forintot spórolhatunk vele.

NVIDA GeForce RTX 3080 GPU	ASUS TUF Gaming GeForce RTX 3080 OC 10 GB

Abu85, Wombath

A TUF Gaming GeForce RTX 3080 OC videokártyát az ASUS Magyarországtól kaptuk kölcsön.