Bevezető és versenytársak

Nem szeretnénk ismételni magunkat az AMD CPU- és GPU-részlegének utóbbi pár évben elért eredményeinek összehasonlításával, hiszen megtettük azt már a Radeon VII kapcsán, ezért is vártuk nagyon kíváncsian, hogy a felhasználói piacon már tényleg matuzsálemnek tekinthető GCN-t leváltó RDNA-val sikerül-e végre valami tényleg újat alkotni. Az, hogy a részletesebben elsőként az E3-on bemutatott új RX 5700-as szériával most nem az csúcskategóriában akar az AMD versenyezni, hanem inkább az anyagilag jobban kifizetődő felső-közép és középkategóriában, már jó ideje világos volt mindenkinek, aki követni szokta az új termékeket bejelentő eseményeket; míg például a Computexen megtartatott sajtótájékoztatón a harmadik generációs Ryzeneket és a Rome-ot az egekbe magasztalták az Intellel szemben, addig a korábban Navi kódnéven futó GPU-val kapcsolatban nem voltak ilyen agresszívek.

[+]

Ez azonban nem jelenti azt, hogy ezek a grafikus kártyák ne lennének nagyon is fontosak: ha megnézzük az AMD legutóbbi két GPU újdonságát, akkor kiderül, hogy ezek igazából afféle kényszermegoldások voltak: az RX 590 esetében is erősen kilógott a lóláb, hogy az AMD-nek valójában nincs más lehetősége, mint időnként leporolni egyet-egyet az előző évek sikeresnek mondható GPU-i közül, és új gyártástechnológiával, némi áttervezéssel egy-egy piaci rést megcélozva a porondra lépni. Az idén tavasszal érkező Radeon VII még kevésbé nevezhető újnak, ez tulajdonképpen a 7 nm-es gyártástechnológia demójának tekinthető, hiszen alig volt elérhető a boltokban, a cél itt – ahogy akkor is írtuk – az új node kapcsán egy ismert architektúra segítségével végzett tapasztalatgyűjtés (is) lehetett.

Az, hogy ez a tapasztalatgyűjtés mennyire volt hatásos, most fog kiderülni, hiszen egyszerre vált technológiát a CPU- és a GPU-részleg: az előbbinél a Ryzen harmadik generációja, az utóbbinál pedig jelen írásunk tárgya, a Navi az, amelyik 7 nm-es alapra építkezik, és próbálja meg kihasználni ennek előnyeit.

Ütésváltás

Bár a GPU-k tulajdonképpen kétszereplős piacán nem szokatlan, hogy a gyártók szorosan figyelemmel követik a másik mozdulatait, mégis meglepő volt látni az elmúlt pár nap történéseit. Az E3-as bejelentéskor még nagyjából tisztának tűntek a vonalak: a Radeon RX 5700-at a GeForce RTX 2060 és 2070 közé, az RX 5700 XT-t pedig a 2070 fölé szánja az AMD. Aztán hirtelen történt valami: az NVIDIA egyszer csak bejelentette az RTX sorozat frissítését, melyek érkezése szinte pontosan az új Radeonokkal együtt várható. A neten megjelent hivatalos árakat, illetve az eddig megjelent tesztekben mért gyorsulást nézve nem volt nehéz felfedezni, hogy a cél a versenyelőny megtartása/növelése az AMD-vel szemben (amit jól mutat, hogy az ilyen szempontból kevésbé érdekes RTX 2080 Super a többihez képest jóval később, csak július 23-án érkezik).

[+]

Azt, hogy az RTX Super sorozat megjelenése komolyan veszélyeztetheti az RX 5700-as család sikerét, az AMD is látja, így az utolsó pillanatban, gyakorlatilag az indulás előtt vágott az RX 5700 és az RX 5700 XT ajánlott áraiból, a gyárilag tuningolt, limitált szériás RX 5700 XT Anniversary Edition-éből viszont nem. Az, hogy ez mire lesz elég a GeForce-okkal szemben, természetesen nagyban függ a kártyák teljesítményétől is – melyet a most következő oldalakon vizsgálunk meg.

Itt az új architektúra

Az AMD legutoljára 2011-ben mutatott be igazán új grafikus architektúrát. Az akkor leleplezett GCN, vagyis Graphics Core Next persze számos komoly változáson átesett az elmúlt évek során, a Vega termékcsaládon belül például igen sok újítást kapott, de sok tekintetében az alapvető működés nem módosult. Bizonyos szempontból nem is feltétlenül szükséges teljesen új alapokról indulni, hiszen a nagyjából egy évtizede bemutatott utasításarchitektúrákat az AMD, illetve tulajdonképpen az NVIDIA is eléggé skálázhatóra tervezte, vagyis pusztán a szálkezelés, valamint a memóriamodell terén még bőven jó az, amit az első GCN, illetve az NVIDIA Fermi letett az asztalra. Ezeket csak módosítgatni kell, de nagyon komolyan egyikbe sem érdemes belenyúlni, amíg működnek.

A fentiek azonban nem jelentik azt, hogy a mai grafikus vezérlőkkel minden rendben van. Az nyilván nagyszerű, hogy régebben bevezetett utasításarchitektúrák hardveres szálkezelésével és memóriamodelljével még nincs semmi probléma, de ettől a hardvereken belül lehetnek más limitek, amelyeket érdemes kezelni. Ezért is történnek az AMD, illetve az NVIDIA oldalán bizonyos időközönként olyan változások, amelyektől ugyan az utasításarchitektúra működése nem igazán módosul, de magán a dizájnon optimalizálnak a tervezők. Utóbbi két tényezőt több dolog is okozhatja: egyrészt elképzelhető, hogy bizonyos konfigurációk tekintetében már nem skálázódik jól az eredeti kialakítás, másrészt az alkalmazások is fejlődnek, így más jellegű kódokra számítanak a gyártók. A legtöbb esetben mindkét opció szerepet játszik a módosításokban, és ugyan az utasításarchitektúrához az AMD és az NVIDIA régóta nem nyúlt hozzá igazán, a hardverek kialakítása kisebb-nagyobb lépcsőkben fejlődik.

Az AMD-nél leginkább a kisebb lépcsők voltak megfigyelhetőek, míg az NVIDIA lépett nagyobbakat is. Persze nehéz meghatározni, hogy egy dizájnnak mekkora mértékű ugrás kell, hiszen például a GCN már 2011-ben is memóriaalapú (szakmai kifejezéssel pure bindless) architektúra volt, míg az NVIDIA hasonlót a Turinggal vezetett be (addig slot-alapú, bindless dizájnnal dolgoztak), de ahogy változik az API, illetve változnak a programok, úgy változtatni kell a hardver szintjén is, és ez régóta így van.

A GCN-t leváltó RDNA (Radeon DNS) architektúra egy nagyobb váltásnak tekinthető az AMD portáján belül, mondhatni gigantikusnak ahhoz képest, amit a korábbi években változtattak. A vállalat mérlegelhette a szokásos szempontokat, és kialakítottak egy új generációs dizájnt, ami reményeik szerint megfelel majd az új generációs alkalmazásoknak is.

[+]

Az RDNA az utasításarchitektúra szintjén a jól bevált alapokat használja, persze némileg módosítva. Ahogy fentebb említettük a hardveres szálkezelés, valamint a memóriamodell tekintetében nagyon előredolgoztak a cégek, így továbbra is messze vannak azoktól a határoktól, amelyeket nagyjából egy évtizeddel ezelőtt leraktak. A programok működése viszont megváltozott, illetve a jelenlegi előrejelzések szerint változni fog, amihez a feldolgozási modellel érdemes lehet igazodni.

Ha a GPU-kat általánosan értelmezzük, akkor tulajdonképpen olyan heterogén, több feldolgozót rejtő lapkákról van szó, amelyek az egyes fixfunkciós egységeket kifejezetten adatpárhuzamos végrehajtásra kialakított, úgynevezett multiprocesszorokkal egészítik ki. De már alapvetően a multiprocesszorok szintjén is úgy vannak tervezve a dizájnok, hogy a feldolgozás abszolút tolerálja a memóriaelérésből eredő, tipikusan magas késleltetést. Messze ez a GPU-k legnagyobb előnye, hiszen így kellően jól párhuzamosítható feladatokban, megfelelő adatmennyiség megléte esetén rendkívül gyorsak tudnak lenni. Ironikus módon viszont ez a legnagyobb hátrányuk is, ugyanis az aktuális dizájnok annyira az adatpárhuzamos végrehajtásra vannak kigyúrva, hogy vannak olyan helyzetek, amelyekben viszont egészen lassúak. Ilyenek például a divergens kódok, amelyeket ugyan lefuttatnak, csak nem lesz hatékony az eredmény, gyakorlatilag minimum a teljesítmény felezésével kell számolni.

Bár a magasabb szintű shader nyelvek az elágazásokat nem tiltják, de ezek a gépi kódban már nincsenek jelen. A GPU-k eleve nem rendelkeznek elágazásbecslővel, aminek a speciális feldolgozási forma miatt igazából haszna se lenne. A hardver tehát már előre meghatározott utasításokat kap, amelynél a feldolgozók fele a kód "if" feltételét hajtja végre, míg a másik fele gyakorlatilag addig nem dolgozik, amíg meg nem kapják a kód "else" feltételét, de ekkor meg a korábban aktívan munkálkodó részegységek fognak pihenni. Végül persze kiderül, hogy melyik elágazás volt a jó, csak elég nagy ennek az ára a tempót tekintve. Ezért van az, hogy a gyártók a divergens kódok kerülésére buzdítják a programozókat, mert ez hardveres szinten nem kezelhető komolyabb teljesítményvesztés nélkül. Igen ám, de ezt könnyebb mondani, mint betartani, vagyis végeredményben egy olyan hardveres megoldás kellene, ami magát a problémát próbálja, ha nem is megoldani, de minimum kezelni.

Az AMD szerint a processzornál használatos elgondolásoknak a GPU-knál nincs sok értelme, túlságosan különbözik a feldolgozási mód, hogy a spekulatív végrehajtás realitás legyen. Az egyetlen lehetőség az egyes csoportokban futó szálak végrehajtási késleltetését minimalizálni, ami szintén nem túl nagy erőssége a mai grafikus vezérlőknek, de legalább egy megoldható probléma.

Mi a GPU-k gondja?

Szándékosan nem vágunk bele abba, hogy az AMD az előző oldalon taglaltakra milyen megoldással állt elő, mivel olyan fogalmakról lenne szó, amelyeket korábban egyetlen cikkünkben sem vizsgáltunk. Éppen ezért előbb érdemes megvizsgálni azt, hogy miképpen működik egy mai modern GPU. Példának jó lehet az AMD Vega és az NVIDIA Turing architektúrája, de ez igazából csak formalitás, az elméleti alapok mindkét dizájnon belül ugyanazok.

Az egyik legfontosabb működési szempont az adatpárhuzamosság. Ez a grafikus vezérlők esszenciája, de gondot jelent az adatok elérése. Ezek a memóriában vannak, vagyis ahhoz, hogy dolgozzunk velük, be kell őket tölteni a regiszterekbe. Maga a folyamat igen drága, akár 100 ns-nyi időt is igénybe vehet, az pedig nem lenne túl előnyös, ha addig a grafikus vezérlők nem csinálnának semmit. Emiatt a hardverek rengeteg konkurens szálat futtatnak. A koncepció nagyon leegyszerűsítve az, hogy ha az egyik szálhoz nincs adat, akkor nézünk egy olyat, amihez már van. Ha ez új adatelérésbe kezd, akkor lesz egy harmadik szál, ami betölthető, és így tovább, megfelelően optimalizált program esetében zömében lesz olyan szál, amit lehet futtatni, amíg a többihez beérkeznek az adatok.

A fenti leírás a közérthetőség kedvéért meglehetősen leegyszerűsített, de most, hogy a rendszer mögöttes koncepciója világos, leáshatunk mélyebbre is. Ha szálról beszélünk, akkor valami olyasmire gondol az ember, mint a processzorok feldolgozási szála. Olyan nagyon messze ez nem is jár az igazságtól a GPU-k esetében sem, de a rengeteg adat miatt ezeket nem túl célszerű egyesével kezelni, így a hardverek működése szempontjából a szálak azonos szemcsézettségű csoportokba vannak rendezve. Erre a gyártók másképp utalnak, az NVIDIA a warp, míg az AMD a wavefront nevet használja, ami tulajdonképpen a lényegen nem változtat. Mivel a Microsoft a shader modell 6.0 bevezetésével ezt a működési modellt már a HLSL programozási nyelv szintjén is kezeli, talán az lesz a legjobb, ha a redmondi óriáscég elnevezéseit vesszük figyelembe a továbbiakban, vagyis a warpot és a wavefrontot szimplán wave-nek hívjuk, a benne csoportosuló szálakat pedig lane-nek.

Ezek után érdemes rátérni a GPU-k legfontosabb részegységére, vagyis a multiprocesszorra. Ha nagyon le szeretnénk ezt egyszerűsíteni, akkor ami a processzornak a processzormag, az a grafikus vezérlőnek a multiprocesszor. A specifikus működés miatt azonban a GPU-k esetében elég sok lehetőség adódik a különböző fizikai felépítések alkalmazására. Ha a tipikusan alkalmazott FP32-t, azaz 32 bites lebegőpontos feldolgozást vesszük alapul, akkor például az AMD Vega multiprocesszora négy darab 512 bites, vagyis a végeredmény tekintetében négy darab 16 utas vektormotort tartalmaz, míg az NVIDIA Turing multiprocesszora is négy részre van osztva szintén 16 utas feldolgozótömbbel. Ez azt jelenti, hogy mindkét architektúra órajelenként 16 operációt tud végrehajtani a legkisebb végrehajtótömböt tekintve, de az ütemezésük ennél bonyolultabb.

Az AMD és az NVIDIA is wave-ekkel eteti a saját 16 utas tömbjeit, de ezek a wave-ek nagyobb méretűek. A Vega esetében 64, míg a Turingnál 32 lane-ből állnak. Ismerve a hardverek fizikai képességeit, könnyen kitalálható, hogy egyik dizájn sem képes egy órajelen belül végezni egy wave-vel. A Vegának ehhez 4, míg a Turingnak 2 ciklusra van szüksége, amiből az következik, hogy az egy munkaelemre levetített IPC (egy órajelciklus alatt elvégzett műveletek száma) rendre 0,25 és 0,5.

Ezzel önmagában nincs semmi baj, a GPU-knál rendkívül fontos, hogy az adatelérés késleltetése át legyen lapolva. Itt tulajdonképpen az történik, hogy egy bizonyos számú wave fut a végrehajtótömbökön, a Vega esetében maximum 10, míg a Turingnál maximum 32. Na de itt a kulcsszó a maximum, ugyanis számos shader programnál ez elérhetetlen, így akár az is előfordulhat, hogy mindkét architektúra esetében egy-egy wave-re csökken ez a szám. Hogy ez miért baj? Nos, a végrehajtótömbökön futó konkurens wave-ek száma határozza meg azt, hogy mennyire hatékonyan lehet átlapolni a memóriaelérés késleltetését. A lényeg, hogy ha egy wave lefutásához adatra van szükség, és azt éppen be kell tölteni a memóriából, akkor legyen egy olyan wave úgymond tartalékban, amelyhez megérkezett az adat, így megkezdheti a munkát.

Felvetődhet a kérdés, hogy mitől is függ, hogy a gyakorlatban mennyi wave futhat egy végrehajtótömbön? Leginkább a betöltött shader programtól, ez ugyanis döntően meghatározza az erőforrás-allokációt. Ezen a ponton dől el, hogy az adott shader mennyi regisztert igényel, illetve compute shaderek esetében még a helyi adatmegosztásra (LDS) is figyelni kell. A manapság használatos modellek mellett elképzelhetőek igen komplex shader programok is, amelyek nem éppen ideálisak a GPU-knak, ezek a hardverek ugyanis statikus erőforrás-allokációt használnak. Ez azt jelenti, hogy gyakorlatilag betöltenek minden adatot a regiszterekbe, illetve opcionálisan az LDS-be, amelyre az adott shadernek szüksége lehet. Mindez elég pazarló, ugyanis az adatbetöltés ténye még nem jelenti automatikusan azt, hogy az eltárolt adatot használni is fogja a futtatott kód, de egyelőre beletörődnek a gyártók ebbe, hiszen egy dinamikus erőforrás-allokációt biztosító hardver tranzisztorköltsége sokkal magasabb lenne.

Az előbb részletezett pazarlás ugyanakkor néha elég fájdalmas, mert elképzelhető, hogy egyetlen wave-hez annyi adatot kell betölteni, hogy az gyakorlatilag elviszi a regiszterek és/vagy az LDS kapacitásának több mint a felét. Ilyenkor nagyon nagy a baj, mert nincs annyi hely, hogy egy másik wave is indítható legyen, vagyis ha egy esetleges adatelérés történik, akkor a végrehajtótömbnek értelemszerűen meg kell várnia, amíg az információ megérkezik a fedélzeti memóriából. Ahogy fentebb említettük, ez úgy 100 ns-nyi időveszteség, és addig ez a hardveres blokk egyszerűen nem tud csinálni semmit.

A gyártók a fentiek miatt adnak egy iránymutatást minden architektúrához, hogy mennyi wave-vel milyen hatékonysággal működnek. Az AMD a Vega esetében azt ajánlja, hogy a maximális számú wave-nek a 70%-a fusson, míg az NVIDIA Turing esetében ez inkább 50-60% közötti. Ezekben az esetekben kellően jó lesz az érintett hardverek kihasználása, hiszen a feldolgozás során szinte mindig lesz egy olyan wave, amelyhez megérkezett már az adat és be lehet tölteni.

Mi a programozók gondja?

Az előbbi oldal alapján igen nyilvánvaló, hogy a hardver szempontjából mire van szükség: sok wave-vel jó lesz a kihasználtság, amivel magas lesz a teljesítmény. Elméletben mi sem egyszerűbb ennél, de a gyakorlat általában más lapra tartozik. A fejlesztőknek a modern GPU-kkal egyszerre van könnyű és nehéz dolguk. Talán nem lesz újdonság, hogy az AMD Vega és az NVIDIA Turing is úgynevezett SIMT dizájn, az érintett cégek elég régóta erre a működésre esküsznek, amelyet viszonylag egyszerű megtanulni, elvégre a wave-ek ugyanazokat az utasításokat futtatják a lane-eken (innen jön a Single Instruction Multiple Thread elnevezés). A programozó szemszögéből nincs explicit szálmenedzselés, se vektorokra való optimalizálás, vagyis a tipikus buktatók már a hardver oldalán meg vannak kerülve.

Van azonban más probléma (amit az előző oldal végén ecseteltünk), nevezetesen a statikus erőforrás-allokáció. Innentől ugyanis arra kell koncentrálni, hogy egy wave minél kevesebb erőforrást igényeljen, amivel nő a futtatható konkurens wave-ek száma. Ezt persze könnyebb leírni, mint megtenni, főleg amiatt, hogy a mai programokban tipikusan elterjedtnek számítanak az úgynevezett übershaderek, amelyek igen komplexek lehetnek. Emellett a GPU-k gyorsítótár-architektúrájának folyamatos fejlődésével ma már érdemes lehet az úgynevezett találati ablakra játszani. Ez egy leginkább konzoloknál alkalmazott optimalizálási technika, ami lassan átszivárog PC-be, és lényegében azt jelenti, hogy a lehetségesnél szándékosan kevesebb konkurens wave futtatását vállalja be a programfejlesztő, hogy megnőjön az az időtartam, amíg az adatok ottmaradnak a gyorsítótárakban, hogy ezeket esetleg ne kelljen újból a fedélzeti memóriából betölteni. Persze ez kockázatos játék, mert a GPU-kon belül rengeteg párhuzamos számítás zajlik, így a gyorsítótárakban is nagyon kevés ideig marad meg az adat, vagyis a találati ablak nem nő meg drasztikusan bizonyos trükkök bevetése mellett. Ettől függetlenül vannak olyan helyzetek, amikor ez egy értékes optimalizálási stratégia, és végeredményben ez hoz majd nagyobb teljesítményt.

A fentiekből látszik, hogy a mai GPU-kra való programozást úgymond könnyű elsajátítani, a régebbi, legalább tíz évvel korábbi hardverekhez viszonyítva mindenképpen, de rendkívül nehéz az optimalizálást mesteri szinten űzni, mert a modern GPU-k működése túl kötött, így relatíve kevés olyan helyzet van, ahol optimális a hatékonyságuk.

Ezektől függetlenül abból kell főzni, ami van, tehát ha a fejlesztők nagyobb teljesítményt akarnak kisajtolni shader programjaikból, akkor be kell tartani az AMD és az NVIDIA nagyrészt hasonló optimalizálási normákat megfogalmazó iránymutatásait. Ezekkel végeredményben igen jól működnek a mai GPU-k, de az alapproblémák ettől még léteznek, csak a szoftverek kezelik őket – már amelyik programban van erre optimalizálás.

Segítség hardverből?

Az AMD-nek az elmúlt években volt ideje elgondolkodni azon, hogy mit kellene módosítani a GPU-k dizájnjain, hogy a fejlesztők munkája egyszerűbb legyen. Tulajdonképpen a nehézséget az okozza, hogy minden grafikus vezérlő egy tipikus működési módra van felkészítve. Például az AMD Vega és az NVIDIA Turing is csak egyféle méretű wave-et támogat, ezeknél ráadásul az egy munkaelemre levetített IPC nem is éri el az 1-et, konkrétan eléggé messze vannak tőle, holott például a GCN előtti legutolsó TeraScale dizájn ilyen paraméterrel rendelkezett, csak ezt a rendszert ugye nehéz volt programozni.

Felmerülhet a kérdés, hogy miért nem állít be az AMD és az NVIDIA inkább 16 lane-ből álló wave-et a Vega és a Turing esetében, amivel elérnék az 1-es értéket az egy munkaelemre levetített IPC tekintetében. Erre igen egyszerű a válasz. Az érintett architektúrákban a multiprocesszorok dizájnja úgy van kialakítva, hogy rendre 64 és 32 lane-nel tudják igazán jól átlapolni a memóriaelérés késleltetését, tehát még ha módosítanák is a hardverek működését, amit valószínűleg meg lehetne tenni, inkább teljesítményt (méghozzá jelentőset) vesztenének a wave méretének csökkentésével, vagyis az egésznek nem lenne semmi értelme.

Az AMD viszont az RDNA architektúrával új alapokra tudta helyezni a magának a multiprocesszornak a kialakítását, vagyis volt lehetőségük arra, hogy a szükséges módosítást elvégezzék a hatékonyság növelése érdekében. Ezt meg is tették, és az új Navi generációban be is mutatkozott az úgynevezett variálható wavefrontméret (vagy wave-méret). Maga a dizájn maradt SIMT, ez a része nem változott, viszont kétféle módon képes mostantól működni. Az egyik az egyszálú teljesítményre és a jobb adatlokalitásra, míg a másik továbbra is a késleltetés átlapolására van optimalizálva. Utóbbi talán nem annyira izgalmas, mert lényegében ugyanazok a hátrányai, amiket nemrég taglaltunk, de az egyszálú teljesítmény és a jobb adatlokalitás furán hangzik egy GPU esetében, viszont van benne ráció.

[+]

Az egyszálú sebességre kitérve ezt nem úgy kell elképzelni, ahogy egy processzornál. Továbbra is adatpárhuzamos a feldolgozás, csak ha mondjuk veszünk a wave-en belül egy lane-t, akkor az operáció időigénye maghatározható. Az AMD Vega és az NVIDIA Turing esetében egy wave rendre négy és kettő ciklusig fut, vagyis egy lane ugyanennyi időn belül ad eredményt. Az AMD Navi azonban képes arra, hogy egy wave-et egy ciklus alatt lefuttasson, vagyis a Vegához képest négyszeres, a Turinghoz képest pedig kétszeres az egy szálra, vagyis egy lane-re levetített teljesítménye. Emellett ez a működési mód azt is lehetővé teszi a Navi esetében, hogy egy wave csak feleannyi erőforrást igényeljen, vagyis a jobb adatlokalitás miatt anélkül nő a találati ablak, hogy erre külön optimalizálni kellene. Mindezek mellett a Navi a legtöbb shadert a Vega architektúrához viszonyítva akár feleannyi órajelciklus alatt végre tudja hajtani, de még a késleltetés átlapolására vonatkozó módban is legalább 40% az előnye, ami eléggé toleránssá teszi a rendszert a divergens kódokkal szemben. Nyilván ezek általános hátrányát az RDNA dizájnja mellett is el kell tűrni, de egyáltalán nem mindegy, hogy mennyi a kötelezően lenyelendő teljesítményveszteség.

Az AMD elmondása szerint az RDNA architektúra esetében kifejezetten figyeltek arra, hogy a modern SIMT dizájnok problémáit levetkőzzék, ezekre ugyanis a cég véleménye alapján tényleg könnyű programozni, de teljesítményt már nehézkes nyerni rajtuk. A Navi felépítése viszont lehetővé teszi, hogy mostantól teljesítményt is könnyebben lehessen szerezni a shader kódok optimalizálása által.

[+]

A variálható wavefrontmérethez kapcsolódó két működési módról egyébként nem a hardver dönt, hanem a grafikus meghajtó fordítója, méghozzá az adott shadert megvizsgálva. Ez az AMD elmondása alapján új technikákat tesz lehetővé a fordító szempontjából. Az elméleti lehetőségek viszont további vizsgálatokat igényelnek, hogy a jövőben esetleg a gyakorlatban is kihasználhatók legyenek.

Az RDNA-ben bevezetett változások egyébként nem azt jelentik, hogy mostantól nem kell majd annyit optimalizálni. A régebbi hardverek továbbra is igénylik a figyelmet, mivel azok abszolút a késleltetés átlapolására vannak kialakítva, tehát amit mondjuk a Navi jobban megold hardverből, az egy korábbi tervezésű grafikus architektúrának nehéz falat lehet.

A Navi mélylélektana

Az új, Navi családba első körben egy lapka jön, Navi 10 jelzéssel. Ez egy 10,3 milliárd tranzisztorból álló, 251 mm²-es fejlesztés, amely a TSMC 7 nm-es node-ján készül. A rendszer gyakorlatilag mindenhol megváltozott a korábbi generációkhoz képest, és az AMD hivatalosan GFX IP 10-nek nevezi, míg a marketingben a már említett RDNA architektúra lesz használatos.

[+]

A Navi 10-es grafikus vezérlőben 20 darab úgynevezett WGP (Workgroup Processor) található. Ezek két darab CU-t, azaz Compute Unintot tartalmaznak, és ezekben belül van két darab, egymástól teljesen független, saját skalár egységekkel dolgozó, 32 utas, azaz 1024 bites, multiprecíziós SIMD motor. Egy WGP-ben 128 kB-os Local Data Share (LDS) található, amelyen a négy darab, egyenként 128 kB-os regiszterterülettel rendelkező SIMD motor osztozik. A helyi adatmegosztás mellett CU-nként egy darab 16 kB-os L0 adat gyorsítótár is fellelhető.

A WGP-n belül a saját regiszterterülettel és wave pufferrel rendelkező skalár egységekhez tartozik egy közös 16 kB-os skalár és egy 32 kB-os utasítás gyorsítótár. Előbbit csak a skalár feldolgozó éri el, míg utóbbit az összes feldolgozó hasznosíthatja, és természetesen mindkét gyorsítótár írható és olvasható is. Ezek mellett a textúrázást CU-nként egy blokk oldja meg, amely négy darab, csak szűrt mintákkal visszatérő, Gather4-kompatibilis textúrázó csatornát rejt.

[+]

Az látható, hogy van változás bőven a korábbi generációs architektúrához képest. A legfontosabb előnyöket az jelenti, hogy mostantól minden 1024 bites SIMD motorhoz tartozik egy skalár egység, és tulajdonképpen ez teszi lehetővé, hogy az adott wave ne csak 64 lane-ből, hanem 32-ből is állhasson.

A korábbi generációs architektúráknál, például a Vega esetében is azért volt egy wave-ben 64 lane, mert mindössze egy skalár egységen osztozott négy darab 512 bites SIMD motor. Tehát a wave-ek kiosztása úgy történt, hogy az első SIMD megkapta az első wave-et, majd ezen dolgozott négy órajelciklusig, amíg a skalár egységnek volt ideje úgymond megetetni a többi SIMD-et is. Mire tehát új wave-et kapott az első SIMD, addigra pont végzett a korábbi feladattal. És itt jön elő az, amit a negyedik oldal elején taglaltunk: hiába lenne kevesebb lane egy wave-ben, mondjuk 16, akkor is csak az történne, hogy az egyetlen egy skalár egység négy órajel alatt megeteti a négy SIMD-et, amelyek négy helyett már egy órajel alatt végeznek a munkával a kevesebb lane miatt. De hiába végeznek hamar, új wave-et nem tudnak kapni, mert a skalár egység el van foglalva, vagyis az elméleti teljesítmény 75%-a odaveszne.

[+]

A fentiek miatt tartozik mostantól minden SIMD-hez külön skalár egység, amely minden egyes órajelben tud biztosítani egy 32 lane-ből álló wave-et, amit aztán az adott SIMD egy órajel alatt le is tud futtatni. A 64 lane-ből álló wave-ek végrehajtása már két órajelig tart, vagyis itt azért egy órajelnyi üresjárata lehet a skalár feldolgozónak, de ez az újfajta dizájn átka, valahol meg kell fizetni a variálható wavefrontméret árát – valószínűleg számított rá az AMD, hogy ez a tranzisztorszám növelése lesz. A Navi egyébként maximum 20 konkurens wave-et tud kezelni feldolgozótömbönként.

Az SFU-k, vagyis a speciális funkciókért felelős egységek összesített száma nem változik. CU-nként továbbra is nyolc feldolgozóról beszélünk, csak a Navi esetében egy SIMD-hez tartozik mind, míg a korábbi architektúrában SIMD-enként néggyel lehetett számolni.

[+]

Jelentősen átalakult még a gyorsítótárak szervezése. A memóriavezérlőhöz egy 4 MB kapacitású, írható és olvasható másodlagos gyorsítótár és 4 darab ROP blokk kapcsolódik. Ezek a ROP blokkok úgynevezett pixelmotorokat tartalmaznak, egészen pontosan 4-et, és egy pixelmotor 4 blending, illetve 16 Z mintavételező egységből áll, ami összesen 64 blending és 256 Z mintavételezőt jelent. A ROP blokkok – a korábbi Vega architektúrához hasonlóan – ezúttal is a másodlagos gyorsítótár kliensei, vagyis a pixel- és textúraadatokra vonatkozó memóriaelérések koherensek. Ami itt érdekesség, hogy minden ROP blokk saját RB gyorsítótára egy olyan 128 kB-os L1 gyorsítótárhoz kapcsolódik, amelyet még öt darab WGP is elér, és ezek az egységek a raszterizálóval együtt ezen osztoznak. Strukturálisan ez viszonylag nagy átszervezés, de további tényező még, hogy a gyorsítótárak késleltetése 21-24%-kal csökkent a korábbi architektúrákhoz viszonyítva. Mindemellett az L1 gyorsítótárhoz kapcsolódik a CU-khoz tartozó L0 is, és utóbbi sávszélessége a korábbi generáció hasonló részegységéhez képest meg is duplázódott.

[+]

Természetesen megmaradt a Delta Color Compression technika, amely továbbra is teljes mértékben támogatja a 2:1, a 4:1 és a 8:1 arányú, veszteségmentes tömörítést, így jelentősen lehet vele csökkenteni a memóriabuszra vonatkozó terhelést. Sőt, a Navi esetében az AMD gyakorlatilag mindenhol DCC-t használ, ahol van értelme, így az egyes részegységek és a gyorsítótárak között is. Végül érdemes szót ejteni a memóriavezérlőről, amely 256 bites, és nyolc darab 32 bites buszon köthető rá egy-egy darab GDDR6 szabványú memórialapka.

NGG, ami teljesen működik

A Navi 10 geometriáért és raszterizálásért felelős rendszere is teljesen új, ráadásul nagyon fura a felosztása. A korábbi architektúráknál leginkább azt láttuk, hogy a skálázhatóság érdekében gyakorlatilag több részre voltak bontva a szóban forgó részegységek. Ennek az előnye nyilván a skálázás, vagyis a számítási teljesítmény növelésével a grafikus vezérlő egyéb képességei is javultak, így nem keletkezett szűk keresztmetszet, ami rontaná a hatékonyságot. A GPU-k azonban heterogén többmagos processzoroknak tekinthetők, tehát a skálázás érdekében ugyan jó az egyes részegységeket felosztani, majd a számukat növelni, de ilyenkor egyre többször fordul elő az a helyzet, hogy valamelyik shader blokk rengeteg compute feladatot kap, és olyankor a geometriai motor nem tud csinálni semmit.

Az AMD szerint ez tranzisztorpazarlás, így a korábban alkalmazott strukturális felépítést átalakították. A fő alapegység a shader motor, amelyből kettő van a Navi 10-es GPU-n belül. Ezek két-két compute blokkra vannak osztva, és egy-egy compute blokkon belül van egy 128 kB-os L1 gyorsítótár, öt darab WGP, négy pixelmotor, egy raszterizáló és egy Prim egység.

Az új geometriai motor alapvetően egyetlen egy geometriai processzorból áll, amin belül persze számos, részfeladathoz kapcsolódó egység van, de ezek egyik compute blokkba sincsenek direkten bekötve, ahogy például a korábbi generációknál. A célja ennek a koncepciónak az, hogy ha egy compute blokkon belül esetleg csak compute shaderek futnak, akkor a hardver ne veszítse el az adott blokkba épített geometriai részegység teljesítményét. Ezzel a felépítéssel a geometriai processzor megosztható mind a négy compute blokk között, vagy akár egy blokkhoz is hozzárendelhető, vagyis maximálisan lehet alkalmazkodni az adott feladathoz. Az említett egységen belül egyébként minden olyan elem továbbfejlesztett verziója megtalálható, ami a régebbi hardverekben benne volt.

A geometriai processzorhoz compute blokkonként kapcsolódik egy-egy raszterizáló, aminek a képessége megegyezik a Vega architektúrában bemutatkozóval, tehát az IMR mód mellett támogatja a DSBR, vagyis a draw-stream binning rasterizer módot is, ami nem csak gyorsítja a feldolgozást azzal, hogy a lapkán belül tartja a számításokat, hanem még a fogyasztást is csökkenti a memóriabusz terhelésének visszafogásával.

[+]

Újdonság az a Prim egység, ami szintén a geometriai processzorhoz kapcsolódik, és compute blokkonként egy van a GPU-n belül. Ez segíti a nem látható háromszögek korai kivágását. Itt érdemes visszautalni a Vega 10 egyik érdekes újítására, vagyis az NGG-re, ami utólag csak részben került engedélyezésre. Ennek oka az volt, hogy a primitive shader ugyan képes volt működni direkt támogatás esetén, de az AMD úgy akarta ezt megoldani, hogy ezzel a fejlesztőknek ne is kelljen foglalkozniuk. Ez igazából logikus, ha egy fejlesztő korán meg akar szabadulni a potenciálisan felesleges háromszögektől, akkor arra vannak szabványos, compute shaderre épülő megoldások. A vállalat ezért nem erőltette a primitive shadert, mert ez direkt támogatás esetén a Vega architektúrára korlátozta volna az egyes programkódokat. A compute shadereket viszont régóta támogatja minden GPU, tehát egy grafikus motoron belül igenis a szabványos kivágási technikákat érdemes célozni.

Az AMD ma is olyan rendszert képzel el, amelyet a fejlesztőknek nem kell direkten támogatni. Elég, ha a megszokott módon írják a programokat, a shader fordító majd a háttérben elvégzi azokat a feladatokat, amelyek ahhoz szükségesek, hogy az NGG mód teljesértékűen üzemeljen. Ez volt a Vega esetében is a terv, csak maga a hardver nem működött megfelelően, és információink szerint a háromszögek kivágása terén hozott néha problémás döntéseket. A Navi esetében azonban a vállalat korrigálta a problémákat, így az NGG mód már teljes mértékben aktív. Ennek persze szerves része a shader fordító is, hiszen el kell dönteni, hogy a vertex és geometry shadereket hogyan fordítsák le a hardver felé, de ez már szoftveres optimalizálás kérdése, vagyis maximum javulni fog a jövőben a hatékonyság, a hardver viszont már most működik.

Az ebből származó előnyt nehéz pontosan meghatározni, mert az NGG mód nem kikapcsolható, illetve az AMD szerint nagyon sok függ az adott alkalmazástól. Annyi biztos, hogy hatása mindenhol pozitív, és ehhez igazából tényleg nem kell tenniük semmit a programozóknak, a mai szabványos kódokat elemezve a meghajtó dönt minden kérdésben, a hardver pedig dolgozik, ha esetleg primitive shadereket kap.

Parancsmotorok, multimédia, kijelzőkezelés

Az általános számítások terén is tartogat meglepetéseket a Navi 10. Ez külsőleg nem látszik, hiszen alapvetően négy ACE dolgozik a hardverben, amelyek egy HWS (Hardware Scheduler) fennhatósága alá tartoznak. Ezzel a rendszer összességében 32 compute parancslistát kezel egy grafikai parancslista mellett. Természetesen megmaradt a finomszemcsés preempció és a QoS (Quality of Service) támogatása. Előbbi felel azért, hogy a kritikus fontosságú feladatok előnyt élvezzenek, míg utóbbi a többfelhasználós környezet hatékony kezelését teszi lehetővé, ráadásul továbbra is virtualizálható a teljes lapkára, mindezt teljesen automatikus hardveres ütemezés mellett. Természetesen továbbra is a rendszer része a 64 kB-os globális adatmegosztás, vagy más néven Global Data Share (GDS).

[+]

Látszólag tehát a Vega köszön vissza, de a Navi 10-ben már modernizált ACE egységek vannak, amelyek támogatják az úgynevezett priority tunnelinget. Ez igazából akkor hasznos, ha egy olyan, grafikai számításokkal aszinkron módban futtatható compute futószalag érkezik, amelynél nagyon fontos, hogy a lehető leghamarabb végezzen. Ilyenkor a hardver képes arra, hogy a nem kritikus futószalagokat felfüggessze, és a lehető legtöbb erőforrást biztosítsa a magas prioritású feladatnak. Ez leginkább jobb VR élményhez vezethet, hiszen csökkenthető bizonyos képkockák elkészültének ideje, illetve a Vulkan és DirectX 12 API-kat használó, aszinkron compute-ot támogató játékokban is lehet előnye.

[+]

Multimédiás szinten az AMD eldobta az UVD és a VCE egységet, és ezek helyére érkezik a Radeon Media Engine (RME), ami tulajdonképpen tartalmaz dekódolást és kódolást biztosító blokkot, csak mostantól ezekre nem utal külön a cég. Előbbi Full HD 360 Hz-es, 4K 90 Hz-es vagy 8K 24 Hz-es HEVC videók dekódolását tudja biztosítani, míg utóbbi 360 Hz-es Full HD vagy 60 Hz-es 4K HEVC videók kódolásával bánik el. Mindezek mellett a H.264-es formátum kezelése is megoldott, dekódolás esetén 4K 150 Hz-es, kódolás során pedig 4K 90 Hz-es szinten, Full HD mellett pedig rendre 600 és 360 Hz-cel lehet számolni. Mindezek mellett a VP9 is támogatott, de csak a dekódolás erejéig, itt viszont 90 Hz-es 4K vagy 24 Hz-es 8K lehet a videó, továbbá a TrueAudio Next is elérhető.

[+]

A kijelzőmotor sem maradt érintetlen. Egyrészt a Navi tudja mindazt, amit a Vega generáció, de emellett kompatibilis a DisplayPort 1.4 kiegészítésének tekinthető Display Stream Compression 1.2a technológiával, amivel egyetlen aljzatról biztosítható egy 240 Hz-es 4K vagy egy 60 Hz-es 8K HDR kijelző meghajtása.

[+]

Érdemes még kiemelni, hogy a Navi 10 az első, felhasználói piacra szánt grafikus vezérlő, amelyik támogatja a PCI Express 4.0-t – ehhez persze X570-es alaplap, illetve Ryzen 3000-es processzor szükséges. Az AMD szerint ennek jelen pillanatban leginkább professzionális szinten van haszna, például a ProRes4x4 8K 60 fps-es lejátszás a DaVinci Resolve 16 (beta) alatt valóban 60 fps lesz, szemben a PCI Express 3.0 által lehetővé tett 36 fps-sel. A játékokban azonban nincs még feltétlenül haszna az új lehetőségnek, maximum alig kimutatható mértékben.

A kártyák

Tesztünkben tehát a GPU-k piacának felső kategóriáját vizsgáljuk – egész pontosan az RX 5700-at és 5700 XT-t állítjuk az RTX 2060, 2070 és 2080 ellenébe. Illő volna az utóbbiakból a Super családot is bevenni a sorba, de az NVIDIA ebben egyelőre nem volt partner, ám szerencsére a neten elérhető tesztek segítségével elég jól be lehet lőni, hogy a frissített GeForce-ok mekkora gyorsulást jelentenek.

[+]

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

A Radeon RX 5700 és RX 5700 XT órajeleivel kapcsolatban annyit megjegyeznénk, hogy az AMD megad egy tipikus magórajelet is, amely rendre 1625 és 1755 MHz. Ez az adat konkrétan azt jelenti, hogy a játékok döntő többségében ennyit biztosan elér a hardver.

Aki már most szemezne az új kártyákkal, azok számára fontos hír, hogy a nem referencia modellekre nyár végéig kell várni, nekik addig be kell érni az általunk is tesztelt változatokkal. Ezen azonban felesleges bánkódni, mert mindkét példány elég jól sikerült darab lett.

[+]

Közös tulajdonságuk a „blower” rendszerű, radiális ventilátorra épülő hűtés, mely 70 mm-es átmérőjű légkavarót használ. Mindkét kártya két foglalatnyi helyet igényel, és az alaplap síkjától számítva 110 mm magasak. Hosszúságban apró eltérést okoz, hogy az RX 5700 hűtése csak a gépházból kifelé nyitott, így ez a kártya 269 mm-es, míg az RX 5700 XT esetében a másik oldalon is van szellőzőnyílás, melynek műanyag kerete 4 mm-t ad hozzá ehhez.

[+]

Mint a képeken is látszik, a légáramlás iránya mellett a hűtés burkolatának dizájnjában is van különbség, ezen felül a tömegben is, az olcsóbb változat 1023, a drágább 1104 gramm. Ezt az eltérést alapvetően az 5700 XT vaskos hátsó hőelosztó és merevítő lemeze okozza, a hűtőrendszer belső felépítésében – amennyire meg tudtuk állapítani – nincs eltérés. Sajnos a Radeon VII-hez hasonlóan a GPU és a bordázat közötti kapcsolatot itt is egy egyszer használatos, speciális hővezető lapka biztosítja, így a kártyákat ugyanúgy nem szedhettük szét.

[+]

Az mindenesetre tény, hogy a formaterv nekünk nagyon tetszett a maga letisztultságával, de különösen az 5700 XT néz ki jól a burkolat és a rajta végigvonuló csíkokat megtörő „horpadással". Az extra tápellátást mindkét esetben 8+6-os csatlakozópáros biztosítja, a megjelenítők felé pedig egy sorban három DisplayPort és egy HDMI kivezetés képes biztosítani a kapcsolatot.

Tesztkonfiguráció, szoftverek

A hét nanométeres váltás nem hagyta érintetlenül tesztrendszerünket sem: a legnagyobb változást az AMD biztosította Ryzen 7 3700X megjelenése jelenti, melyet továbbra is egy ASUS ROG Crosshair VII Hero (Wi-Fi) alaplapban üzemeltetünk, természetesen a legfrissebb, ezzel a processzorgenerációval is működőképes BIOS telepítése után. Ezzel párhuzamosan telepítettük a Windows 10 Pro 1903-at is.

Tesztünkben az egyes GPU-kat a következő grafikus kártyák képviselték:

• AMD RX Vega 64: Sapphire Nitro+ RX Vega 64
• AMD Radeon RX 5700: AMD Radeon RX 5700
• AMD Radeon RX 5700 XT: AMD Radeon RX 5700 XT
• NVIDIA GeForce RTX 2060: ASUS ROG Strix RTX 2060 OC
• NVIDIA GeForce RTX 2070: ASUS ROG Strix RTX 2070 OC
• NVIDIA GeForce RTX 2080: ASUS ROG Strix RTX 2080 OC

A hardver mellé a mérésekhez használt szoftvercsomagot is frissítettük és bővítettük a következőképpen:

Eredmények

Jöjjenek akkor most szép sorban az eredemények!

[+]

[+]

[+]

[+]

[+]

[+]

[+]

[+]

[+]

[+]

A grafikonokból jól láthatóan kirajzolódik az a sorrend, amelyet az AMD az előzetes információk alapján látni szeretne: az RX 5700 többnyire az RTX 2070-nel állítható párba, míg az RX 5700 XT ehhez képest egy nagyjából 10 százalékos gyorsulást produkál, és ugyan nem éri el az RTX 2080-at, azért ez a teljesítmény arra elég, hogy az új játékokon a QHD felbontás maximális minőségi beállítások mellett is használható legyen, de némi minimális kompromisszumot kötve a 4K is bőven a játszhatósági határ fölött van.

Ebbe az piros csapat számára az eredeti árakat figyelembe véve ideális képbe persze kissé belekavart az RTX Super kártyák megjelenése, melyek nagyjából 16-17 százalékos gyorsulást hoznak a korábbi változatokhoz képest, más szóval a 2060S a 2070 sebességét hozza, a 2070S pedig már a 2080-at közelíti. Pontos mérési adatok birtokában ezek persze csak durva becslések, és ennek megfelelően csak óvatosan ábrázolhattuk a diagramokban, de az értékelésnél majd kitérünk arra, hogy ez mit jelenthet nekünk, vásárlóknak, különösen az AMD utolsó pillanatos árcsökkentésének fényében.

Fogyasztás, frekvencia, hőmérsékletek

Már a Radeon VII kapcsán is láthattuk, hogy a 7 nm-es node milyen hatással van a fogyasztásra, hiszen a hasonló architektúrára, de 14 nm-es technológiára épülő Vega 64-hez képest egy kellemes 20 százalékos órajeltöbbletet kaptunk ugyanakkora TDP mellett is.

[+]

[+]

Ugyanez látható az RX 5700 és 5700 XT-nél is, amelyek tényleg impozánsak, hiszen az eddig a teljesítményhez szükséges fogyasztás területén sokkal jobban teljesítő RTX szériát is sikerült utolérni, sőt pár százalékkal még lehagyni is.

[+]

Csak érdekességképpen megmutatjuk a hőmérsékletek alakulását is, amely inkább csak azt mutatja, hogy a kisméretű, bloweres gyári hűtések teljesítménye mennyivel marad el az egyedi kártyákra szerelt, többventilátoros monstrumokétól. Ez bizakodásra adhat okot a későbbi tuningpotenciállal kapcsolatban, annál is inkább, mert a frekvenciát mutató görbén látszik, hogy a Navinak nem okozott gondot a Strange Brigade háromszori futtatása során szépen tartani a sebességet.

[+]

Elég látványos a GPU-Z által mért fogyasztási adat, és bár az ilyen értékeket sosem tekinthetjük teljesen megbízhatónak, elég jól látszik, hogy a Navik fogyasztása egyáltalán nem alakul rosszul, ha az általuk nyújtott teljesítményt is figyelembe vesszük.

Értékelés

Egyelőre nem a Navi fogja megváltani a világot, és Jensen Huangnak sem kell még megválni valamelyik sportkocsijától. Ennek ellenére az AMD-nek sikerült egy olyan terméket letennie az asztalra, amellyel a cég újra versenyképes alternatívát tud kínálni abban a szegmensben, amely a vásárlók elég nagy százalékának érdekes, és azt mutatni, hogy később némi csiszolással akár a csúcskategóriát is beveheti.

[+]

[+]

Az eredményeket nézve a 2080-ra túl sok szót nem vesztegetnénk, számára az RX 5700 XT sem ellenfél, esetleg a gyárilag húzott RX 5700 XT 50th Anniversary Edition tudja megközelíteni. Az RX 5700 XT inkább a következő napokban érkező GeForce RTX 2070 Super ellenfelévé vált: annál várhatóan pár százalékkal lassabb lesz, de az utolsó napok áresésének következtében ár/értékben mégis jobb vételnek tűnik. Ez a grafikus kártya jelenleg azoknak lehet jó, akik maximális minőségi beállítások mellett a QHD-t célozzák, de a 4K felbontásba is belekóstolnának, esetleg csak minimálisan csökkentve a képminőségen. Ez a GPU a tetszett és az ajánlott cím között billeg nálunk, de megelőlegezzük neki az utóbbit a nem referencia hűtéssel nyerhető extra teljesítményre számítva.

A Radeon RX 5700 egyértelműen az ár/érték bajnokának tűnik jelenleg, és így teljes mértékben megérdemli az ajánlásunkat, hiszen megbízható teljesítményt nyújt a 2560x1440 pixeles felbontáshoz, tudásához mérten teljesen jó fogyasztással. Ezt a kártyát a GeForce RTX 2060 Super szorongathatja meg a piacon, de itt ismét az a helyzet, hogy az utolsó napos módosítással az AMD-nek sikerült ezen a téren kifogni a szelet az NVIDIA vitorlájából.

[+]

[+]

Változás a legutóbbi pár AMD-s bemutatóhoz képest, hogy most mind ár, mind elérhetőség tekintetében ütősnek tűnik a termék. Az RX 590 esetében az előbbivel akadtak gondok, míg a Radeon VII-nél az utóbbival. Most azonban úgy tűnik, hogy a Navinál az AMD tényleg bevet mindent, még az utolsó napokban is hajlandó módosítani az árakon, ha ez kell a sikerhez. Amit sajnálunk, hogy a nagyobb számban elérhető egyedi kártyákra még egy hónapot várnunk kell – a sikerhez talán jobb lett volna ezt a folyamatot kicsit felgyorsítani, hiszen így a boltokba is hamarabb megérkezhetnének a Radeon RX 5700 és RX 5700 XT-k.

AMD Radeon RX 5700/5700 XT videokártya

Abu85, Wombath

Az AMD Radeon RX 5700 és RX 5700 XT videokártyát az AMD biztosította, az NVIDIA GeForce RTX 2080, 2070 és 2060 videokártyát pedig az ASUS Magyarországtól kaptuk kölcsön.