Leleplezte az új Radeon generációt az AMD

Utolsó mohikánként első csirke

A végletekig elhúzta az AMD az új RDNA architektúrájának bemutatását, ami annak tudatában igen meglepő, hogy a cég szerint már jó ideje szállítják a VGA-kat a kereskedőpartnereiknek. Emiatt kifejezetten bizakodók abból a szempontból, hogy kellően nagy készlettel vágnak neki ennek a kalandnak, ami egyébként az utóbbi időszakban nem volt jellemző ezen a piacon.

Az RDNA 4-ről már most tudni, hogy a teljes RDNA sorozat utolsó képviselője lesz. Utána az UDNA dizájnok jönnek, amelyekről most még nem érdemes beszélni, de a távolabbi cél az, hogy egységesítsék a CDNA és az RDNA legjobb képességeit. Addig viszont az RDNA 4 a megfogható termék, és a jelenlegi generációba az AMD két GPU-t tervez. Az egyik ezek közül a most bemutatkozó Navi 48, a másik pedig ennek a kisebb testvérének számító Navi 44 lesz.

A vállalat ugyan nem fejtette ki részletesen, hogy az egyes döntéseiket miért hozták meg, de az RDNA 4-nek több célja lesz. A fejlesztés többek között gyors áthidaló megoldásként szolgál majd az UDNA megérkezéséig, mivel az aktuális generációváltás pont úgy jött ki, hogy nehezen volt elérhető valamelyik új TSMC node. Ez viszont a következő évben megváltozik, és igen sok 3 vagy akár 2 nm-es kapacitás épül ki, így könnyedén lehet majd ezekre ugrani. Emiatt is jön csak két lapka, hogy a mérnöki erőforrás már az új generációra koncentráljon, és addig is a jelenlegi generációban kipróbálnak pár olyan dolgot, amit soha nem próbált még ki senki GPU-ban. Emiatt mondható az, hogy az RNDA 4 egyszerre utolsó mohikán és első csirke is.

A cég szerint az RDNA 4 két fő felfogás mentén készült. Egyrészt alkalmaz olyan új megoldásokat, amelyek tipikusan koncentrálnak a mai GPU-dizájnok gyenge pontjainak javítására, ezzel a hatékonyság növelésére, méghozzá úgy, hogy ezeket a program oldaláról támogatni se kell. Másrészt pedig nem nyúljon hozzá az olyan új komponensekhez, amelyek nem optimálisak tömeggyártásra, vagyis felvállalja azokat az optimális kompromisszumokat, amelyek olcsón gyártható, nagy mennyiségben elérhető VGA-kat eredményezhetnek.

[+]

A fentiek kockázatosak, mert így az AMD nem is akar versenyezni a csúcskategóriában, elvégre szándékosan lemondanak például a GDDR7 használatáról, csupán azzal az indokkal, hogy a memória még nem alkalmas arra, hogy a rá épülő termékek tömegesen és olcsón elérhetők legyenek. Ugyanakkor a cég bízik abban, hogy az RNDA 4-ben bevezetett újításokkal kompenzálják a memória-sávszélesség hiányának jó részét. Nem mellesleg az újítások az UDNA-hoz készültek alapvetően, onnan lettek az RDNA 4-be visszaemelve, így élesben is kipróbálhatják őket.

Nagy eltérés viszont az előző generációhoz viszonyítva, hogy eltűnt a chiplet felépítés. Az AMD szerint ez azért alakult így, mert a chiplet stratégia nagy előnye az, ha a teljes piacot részletesebben szeretnék lefedni. Az RDNA 4 esetében ugyanakkor nem a teljes szegmenst, hanem annak a nagy eladásokat biztosító szeletét célozzák meg. Ez azért is van így, mert a vásárlók döntő többsége 300-600 dollár között vesz magának VGA-t, amit a piackutatások is megerősítenek. Eközben a legnagyobb szegmentálás a 600 dollár feletti régióban van, ami a piac kis szeletének számít. Ide minimum kellene legalább kettő, de inkább három darab hagyományosan tervezett GPU. Ergo, ha le akarnák fedni a teljes területet, akkor a chiplet jó alternatíva lenne, mert összességében kevesebb lapkát kellene tervezni. De a piac, AMD által megcélzott részére elég két GPU. Ilyenkor már hátrányos a chiplet stratégia, mert ezzel három lapkát kellene elkészíteni minimum, chiplet nélkül viszont megúszták két lapkával.

RDNA negyedszer

Az RDNA 4 architektúra elsőként a Navi 48 kódnevet viselő, 357 mm²-es kiterjedésű GPU-n debütál, amelyet a TSMC 4 nanométeres eljárásán gyárt a cég, benne pedig 53,9 milliárd tranzisztor található. Az AMD a dizájnkönyvtár tekintetében meglehetősen agresszíven ment rá arra, hogy minél sűrűbben tudják elhelyezni a tranzisztorokat. Ez általában kedvezőtlen szokott lenni az elérhető órajelre nézve, de sokat dolgoztak ennek a kompenzálásán, így az új GPU is képes 3 GHz körül, esetlegesen fölötte működni.

[+]

A multiprocesszorra levetített részletek tekintetében a Navi 48-ban 32 darab úgynevezett WGP található. Egy ilyen tömb két darab CU-t, azaz Compute Unitot tartalmaz, és ezeken belül van két darab, egymástól teljesen független, saját skalár egységekkel dolgozó, 64 utas, azaz 2048 bites, multiprecíziós SIMD motor. Ez a része a dizájnnak nem változott az RDNA 3-hoz viszonyítva, tehát a korábban beépített képességek, mint például az úgynevezett VOPD mód ezúttal is elérhető, a variálható wavefrontméret pedig már az első generációs RDNA óta jelen van. Kicsit módosult viszont a skalár egység, ugyanis ez ezentúl támogat FP32 operációkat is, ami hatékonyabbá teheti az egyes erőforrások feldolgozását az explicit API-kon belül.

Jelentős továbbfejlesztést kapott az ütemező, ami mostantól bizonyos operációkat gyorsít, de ennél is fontosabb, hogy a korábbiaknál kedvezőbben kezeli az erőforrás-korlátozásokat, amivel javulhat az utasítás szintű párhuzamosság. Ezek mellett jobb hatásfokú utasítás-előbetöltést is hoz a rendszer, amely ráadásul szoftveresen kontrollálhatóvá válik. Az RDNA 4 az előző generációhoz viszonyítva az előbetöltési távolságot négyszeresére növeli, miközben maga az előbetöltés rugalmasan meghatározható, akár egy valószínűleg bekövetkező elágazási ágra irányítható. Utóbbival hatékonyabb lehet az utasítás gyorsítótár kihasználása.

Túllépve a vektormotoron, vissza lehet térni a WGP-hez, amelyben 128 kB-os Local Data Share (LDS) található, és ezen a négy darab, egyenként 192 kB-os regiszterterülettel rendelkező SIMD motor osztozik. A helyi adatmegosztás mellett CU-nként egy darab 32 kB-os L0 adat gyorsítótár is fellelhető.  A WGP-ken belül a saját, 8 kB-os 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 SFU-k, vagyis a speciális funkciókért felelős egységek összesített száma nem változott, azaz vektormotoronként nyolc feldolgozóról beszélünk, illetve adott még a dupla pontosságot biztosító egy szem 64 bites feldolgozó is.

A CU-k része még az AI gyorsító, amely nagy fejlesztésen ment át az RDNA 3-hoz viszonyítva. Ez technikailag egy 64 utas matrixfeldolgozó, amely különböző, 4, 8 és 16 bites tensor adattípusokat kezel, 16 és 32 bites akkumulátorokkal, sparsity támogatással. Ezek jó része alapvető újítás a korábbi dizájnhoz képest, és azt a célt szolgálják, hogy nagyobb teljesítményt biztosítson a rendszer AI feladatok feldolgozása során. Az RDNA 3-ban is támogatott tensor adattípusok esetében – sparsity-től függően – az RDNA 4 kétszer, négyszer vagy nyolcszor gyorsabb, továbbá új, 8 bites adattípusokat vezet be. Ezen belül is FP8-ról és BF8-ról van szó. Mindkét esetben 1 jelbit van, de amíg előbbi 4 bites exponenst és 3 bites mantisszát használ, addig utóbbinál rendre 5 és 2 bitre lehet számítani.

A gyorsítótárak szervezése logikailag az előző generáció továbbfejlesztésének tekinthető. A memóriavezérlőkhöz a 64 MB kapacitású, Infinity Cache nevű írható és olvasható gyorsítótár kapcsolódik, és a 8 MB-os, szintén írható és olvasható másodlagos gyorsítótár ehhez van hozzákötve a ROP blokkal egyetemben. Az utóbbi részegységek továbbra is a másodlagos gyorsítótár kliensei, vagyis a pixel- és textúraadatokra vonatkozó memóriaelérések koherensek. Eltűnt ugyanakkor az L1 gyorsítótár a dizájnból, helyette egy jóval kisebb, csak olvasható puffer van, ami főleg a ROP blokkok saját gyorsítótárai közötti adatmegosztásra szolgál. Ez a döntés azzal magyarázható, hogy az eleve írható L2 cache elérése eleve jóval gyorsabb lett, miközben a kapacitása is nőtt, ráadásul szoftveresen partícionálható, így leválasztható belőle egy akkora rész, ami igény esetén tudja pótolni a klasszikus, csak olvasható L1 cache működését.

A ROP blokkok tekintetében a korábbi logikai felépítés maradt meg, vagyis ezek továbbra is úgynevezett pixelmotorokat tartalmaznak, egészen pontosan kettőt, és egy pixelmotor 4 blending, illetve 8 Z mintavételező egységből áll, ami összesen 128 blending és 256 Z mintavételezőt jelent.

Sugárkövetés újragondolva

A sugárkövetés tekintetében az RDNA 4 jelentős újításokat vezet be. A kapcsolódó részegységek továbbra is a textúrázóblokk mellett találhatók, vagyis CU-nként továbbra is egy úgynevezett RA, azaz Ray Accelerator található. Ezen belül viszont már sok a változás, többek között javult a dobozok és a háromszögek metszésvizsgálatának hatásfoka, mivel órajelenként rendre nyolc és két operáció hajtható végre. Ez már önmagában duplázza a tempót, de a hardver kiegészült egy Ray Transform feldolgozóval, ami bejárási folyamat egyes lépcsőin gyorsít.

[+]

A sugárkövetéssel járó feladatok egy kritikus része a BVH gyorsítóstruktúra generálása, illetve az ezzel való munka, és itt az RDNA 4 sokat változott. Egyrészt a rendszer már nem BVH4, hanem BVH8 gyorsítóstruktúrával dolgozik, ami nagyjából 40%-kal csökkenti a memória terhelését, illetve elérhető az úgynevezett OBB képesség, ami az Oriented Bounding Boxes rövidítése.

Az OBB lényegéhez érdemes megérteni a tradicionális BVH gyorsítóstruktúrában a határolódoboz a tengelyek mentén igazított, vagyis minden doboz egyes élei párhuzamosak vagy merőlegesek lehetnek az alkalmazott koordinátarendszer tengelyeire. Ez igazából nem rossz, de vannak olyan geometriák, amelyek ilyen szempontból nem optimálisan helyezkednek el. Ettől még a jelenlegi rendszer ezekkel is tud bánni, de relatíve sok határolódoboz szükséges ahhoz, hogy kezelve legyenek, és ez az esetek többségében azt eredményezi, hogy a hardver feleslegesen számol, mert a dobozok többsége üres lesz, vagyis nem tartalmaz majd geometriát. Ezt persze előre nem lehet tudni, tehát egy szükséges rosszról van szó van szó, viszont ilyen formában igen mély lesz az adott BVH gyorsítóstruktúra.

[+]

Az AMD erre létrehozta az OBB-t, és ez egy olyan határolódoboz, ami nem a tengelyek mentén igazított, hanem inkább a geometriához igazodhat. Ezzel a módszerrel kevésbé mély BVH gyorsítóstruktúra hozható létre, ezáltal csökkentve a szükségtelen számítások elvégzésének arányát. Általánosan elmondható, hogy minél komplexebb egy modell geometriája, annál nagyobb az előnye az OBB bevetésének, mert sok háromszöggel nagyobb a valószínűsége, hogy egy adott háromszög nem fog optimálisan elhelyezkedni. Ezek viszont az RDNA 4 esetében nem kritikus problémák, mert a hardver orientálni tudja a BVH gyorsítóstruktúra határolódobozait.

Az új rendszer másik nagy újítása két részből áll. Az egyik a Pack and Sort, ami az RA feldolgozó része, és hozzá kapcsolódik az LDS-en belül elhelyezkedő Traversal Stack Management. Igazából utóbbi nem is hardverelem, hanem egy kis speciális memóriaszelet, ami segíti a Pack and Sort, de más shaderek esetén is hasznosítható, csak ott nem akkora a jelentősége, mint sugárkövetésnél. A lényege ennek a fejlesztésnek az, hogy sorrendtől független legyen a memória elérése, vagyis az adott SIMD motoron futtatott konkurens wave-ek, azaz azonos szemcsézettségű szálcsoportok elemeinek memóriaelérése ne várjon egymásra. A várakozás ugyanis akkor kifejezetten kellemetlen, ha nincs valamelyik cache-ben találat. Ilyenkor alapból nagyobb késleltetéssel jár az adatelérés, mert a korábbi dizájnokban a találatot eredményező, másik wave-ből származó adatelérések is kényszerűen késleltetve voltak. Az RDNA 4-ben erre nincs szükség. Mostantól a wave-ek egyes szálainak adatelérése hardveresen menedzselt, így ha egy adott wave szerencsés és mindegyik szálához szükséges adat ott van egy közeli gyorsítótárban, akkor maximális hatékonysággal folytatható a munka, függetlenül bármelyik másik wave adatelérési nehézségeitől.

[+]

Ez leginkább sugárkövetés során eredményez majd előrelépést, méghozzá akkor, ha nem koherensek a memóriaelérések. Ilyen helyzet gyakorlatilag minden másodlagos sugár, ugyanis ezeknél nem meghatározható, hogy az egymás melletti kiindulóponttal rendelkező sugarak hol találnak el valamit. Szemben az elsődleges sugarakkal, amelyek a kamera pozíciójából indulnak ki, ezáltal egymással garantáltak koherensek.

Regiszterkezelés dinamikusan

Az RDNA 4 egyik leglényegesebb újítása a regiszterkezelést érte, amit az AMD ugyan összekötött a sugárkövetéssel, de valójában általános megoldásról van szó, még akkor is, ha az aktuális dizájnban a shader fordító opcionálisan dönt arról, hogy melyik shadert fordítja statikus, illetve melyiket új, dinamikus regiszterallokációval.

A lényeg megértéséhez érdemes egy picit elemezni, hogy a mai GPU-k hogyan működnek ebből a szempontból. Legyen szó akármilyen modernebb architektúráról, a feldolgozás alapvetően SIMT jellegű, vagyis a munkavégzést biztosító SIMD motor egy meghatározott számú konkurens wave-et futtat, amikor egy adott shadert betölt. A wave-ek számát az dönti el, hogy az adott shader program mennyi adattal dolgozik, ezeket ugyanis mind be kell tölteni a regiszterterületbe. Persze architektúraspecifikusan mindig van egy maximum megengedett wave mennyiség, de ezt most hagyjuk, ilyen esetben amúgy is optimális a hardverdizájn kihasználása.

A konkurens wave-ek arra szolgálnak, hogy átlapolható legyen a memóriaelérés késleltetése, vagyis az a cél, hogy az adott shader futtatása során, hogy mindig legyen egy olyan szabad wave, amihez már megérkezett az összes adat, így azzal dolgozni lehet. A gondot igazából a komplexebb shaderek okozzák, ugyanis ezek annyira sok adatot használhatnak, hogy kevés lehet nekik a SIMD motorhoz tartozó regiszterterület. Vegyünk egy egyszerű elméleti példát. A shader operációnként 2 kB-nyi adatot használ, ami 32-utas SIMD motorral számolva 64 kB-os regiszterterhelés. Tegyük fel, hogy 128 kB-os a regiszterterületünk, amibe így két wave-hez szükséges adatmennyiség fér bele, tehát a SIMD motoron két konkurens wave futhat. Ez így egészen rosszul hangzik, mert bármennyire is gyors a VRAM elérése, biztosan lesz olyan helyzet, amikor még mindkét wave adatra vár, és ekkor az adott SIMD motor nem csinál semmit, elvégre nem tud mivel dolgozni.

Nem biztos ugyanakkor, hogy szükség van mind a 128 kB-nyi adatra a regiszterből. Sőt, nagyon tipikus, hogy ennek csak a töredéke kell, de mivel a GPU-k regiszterallokációja statikus, ezért nem tehetünk ellene semmit, muszáj betölteni előre a potenciálisan feldolgozásra váró adatokat, még akkor is, ha annak a 90%-a nem is lett hasznosítva. Innen azért látszik, hogy ez egy eléggé pazarló módszer, de mivel a GPU-k korábban eléggé egyszerű shadereket futtattak, nem igazán volt napirenden, hogy a regiszterallokáció dinamikus legyen, mert annak azért vannak extra tranzisztorköltségei. Ergo inkább elfogadták a cégek azt, hogy ez így a működést tekintve igencsak rossz, a komplex shaderek esetében garantáltan nem lesz hatékony a hardver memóriaelérése, de tranzisztorköltségben azért nem olyan kellemetlen kompromisszum.

[+]

Az AMD az RDNA 4-ben ezen változtat, és bevezetik a dinamikus regiszterallokációt. Ez annyit tesz, hogy a hardver csak azt az adatot tölti be a regiszterbe, amire a SIMD motoron futtatott shadernek szüksége van. Ennek alapvető hatása az lehet, hogy még a komplex shader kódok esetében is elérhető az, hogy nagy mennyiségű konkurens wave fusson az új Radeon SIMD motorjain, így garantálva a memóriaelérés optimális átlapolását. Kevésbé kihangsúlyozott dolog, hogy ilyen formában az RNDA 4 a rosszul optimalizált shaderekre is eléggé immunis lehet, hiszen ezek jellemzően ott csúsznak félre, hogy irreálisan nagy regiszternyomást eredményeznek, ami aztán rontja a memóriaelérés hatékony átlapolását. Ezt valószínűleg azért nem hirdeti a cég, mert nem szeretnék azt az üzenetet közvetíteni a programozók felé, hogy mostantól hátra lehet dőlni, el lehet engedni a gyeplőt, majd a hardver megoldja. Nem, nem fogja megoldani. Kevésbé érintheti majd rosszul az RDNA 4-et egy nem optimalizált shader kód, de ettől még az optimalizálás jelentősége fontos marad, már csak a többi architektúra miatt is.

Az RDNA 4 ezen képessége egyébként nem függ a programtól, nem kell direktek támogatni. Az eszközillesztőben szállított shader fordító dönti majd el, hogy az adott shadert statikus vagy dinamikus regiszterallokációra fordítja. És első körben az AMD keverten alkalmazza majd ezt a módszert, ezen belül annyi biztos, hogy a sugárkövetéshez hasznosítják majd az újítást, mert az itt használt shaderek eléggé komoly varianciát mutatnak a regiszternyomás tekintetében. Például a bejárással járó munka eléggé kevés regisztert szokott igényelni, de a korábbi hardvereknek kötelező volt a legrosszabb forgatókönyvre készülnie. Az RNDA 4-ben lehet dolgozni a valós terhelésre, ahhoz szabva a regiszternyomást.

Multimédia és egyéb dolgok

A rendszer egyes elemeinek vizsgálata után érdemes megnézni, hogy strukturálisan hogyan lesz az egész felépítve. A fő alapegység továbbra is a shader motor, amelyből négy darab van a Navi 48-as GPU-n belül. Ezek két-két compute blokkra vannak osztva, és egy-egy compute blokkban van négy darab WGP, viszont a két ROP blokk, a raszterizáló és a Prim egység megosztva érhető el két compute blokk között. Az általános parancskezelést tekintve két ACE dolgozik a hardverben, amelyek egy HWS (Hardware Scheduler) fennhatósága alá tartoznak. Megmaradt a finomszemcsés preempció és a QoS (Quality of Service) támogatása is, amelyek közül 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 első generációs RDNA-ban bevezetett priority tunneling, illetve a globális adatmegosztás, vagy más néven Global Data Share (GDS).

A Navi 48 kódnevű GPU [+]

A memóriabusz 256 bites, a memóriavezérlő pedig GDDR6 memóriákat támogat, ezen belül is 20 GHz-es effektív órajelen működő lapkákat, de ez elvileg mehet feljebb is. Az AMD ugyanakkor kiemelten figyelt arra, hogy jó áron beszerezhető, nagy mennyiségben elérhető memóriákat társítson a dizájnhoz, így a gyártópartnereknek ezzel nem lesz gondjuk.

[+]

Multimédiában a már ismert Radeon Media Engine (RME) egység erőteljes továbbfejlesztése érkezik, és ebből kettő lesz a lapkán belül, amelyek párhuzamosan tudnak dolgozni egymással, vagyis egyszerre történhet kódolás és dekódolás HEVC, H.264, illetve AV1 formátumon. A rendszert itt elég sok újítás érte, amelyek egy része a korábban felvásárolt Xilinxtől származik. Többek között az AV1 kódolás hatékonyabb lett a B-frame-ek által, az egész feldolgozási futószalag késleltetése általánosan csökkent, javult a HEVC tartalmak kódolásának minősége, illetve sokat fejlődött a H.264-es kódolás is, különösen akkor, ha alacsony bitrátájú tartalomról van szó. Mindezeken túl az egyes dekódolási feladatok is hatékonyabban hajthatók végre.

[+]

A Navi 48 bevezeti még a PCI Express 5.0-t, méghozzá 16 sáv mellett, amennyiben a terméket megfelelően felkészített platformban veti be a felhasználó. Mindezeken túl elérhető a TrueAudio Next is.

A kijelzőmotor nagy újítása

A kijelzőmotor tekintetében a továbbfejlesztett Radiance Display Engine lesz bevetve, amely aktív FreeSync mellett képes úgy kezelni két kijelzőt, hogy a GPU alacsony energiaigényű módba kapcsoljon, illetve bekerült egy hardveres flip queue támogatás, ami videolejátszás során képes tehermentesíteni a CPU-t, a videotartalomhoz tartozó képkockák önálló ütemezésével.

A legnagyobb újításnak egy kijelzőmotorhoz tartozó extra részegység számít, amely a Radeon Image Sharpening funkciót emeli új szintre. Ez még 2019-ben mutatkozott be egy akkori meghajtóban, és az aktiválásával élesebb képet lehetett elérni a játékokon belül. Az eredeti implementációt az AMD PAL-ban írta, ami a vállalat által alkalmazott, valamelyest hardverközelibb absztrakciós réteghez kötött programnyelve. Emiatt a Radeon Image Sharpening tulajdonképpen működött, illetve még ma is működik minden GCN-es és RDNA-s Radeonnal, elvégre egy relatíve egyszerű, kontrasztadaptív élesítő algoritmusról van szó. Ennek van egy szabványos, compute shaderben írt változata is Contrast Adaptive Sharpening néven, ami nagyon elterjedt a játékokon belül.

Az AMD szerint a Radeon Image Sharpening továbbra is megmarad, ezt tetszőlegesen lehet ki-be kapcsolni és paraméterezni az AMD Software-en belül. Az RDNA 4-es GPU-k viszont extraként kapnak egy Radeon Image Sharpening 2 nevű eljárást is, ami már nem egy szoftver, hanem egy konkrét hardveres blokk a lapkán belül. Azt nem érdemes kijelenteni, hogy fixfunkciós hardverről van szó, mert igazából egy Xilinx által tervezett, némileg programozható részegység az alapja az egésznek, ami viszont, dedikált erőforrás lévén nem terheli az általános számításokra használt shader feldolgozókat. Persze az eredeti Radeon Image Sharpening amúgy sem volt egy erőforrásigényes eljárás, de a Radeon Image Sharpening 2 már jóval potensebb.

[+]

Az egész fejlesztés célja az volt, hogy a jelenlegi élesítő algoritmusokhoz viszonyítva legyen jobb a képminőség, ugyanis az aktuális technikáknak vannak olyan tipikus problémái, amelyek ugyan kezelhetők, de nem igazán fektet bele senki sem energiát. Elsődlegesen azért, mert a mostani technikák rendkívül jól futnak gyakorlatilag az összes hardveren, és a specifikus gondjaikat leszámítva elég jó a minőségük is. Az AMD viszont úgy gondolta, hogy lehetne ezen javítani, és érdemes is ezen dolgozni, mivel a legfőbb gondok, például a kép zajosodásából eredő túlélesítő hatások megoldhatók, csak nem nagyon törődtek eddig vele.

A Radeon Image Sharpening 2 végeredményben egy meghajtón belül aktiválható, a célhardverre vonatkozó igény miatt csak RDNA 4 dizájnokon működő eljárás lett, ami teljesen független a megjelenített tartalomtól. Mindegy, hogy milyen program fut, milyen API-t használ, mi kerül a kijelzőre, lehet játék, videó, akár a munkaasztal is, a hardver minden esetben működik és élesíti a képet. A képminőség tekintetében egyébként az eredeti szoftveres eljárások tipikus problémáinak kiszűrése volt a fókusz. Emiatt az új megoldás jóval komplexebb, többek között előszűrést alkalmaz, vagyis megkeresi, hogy a képkockán mit érdemes élesíteni, leveszi az eredeti tartalomról a zajt, és hasonló dolgok. Az eredmény tekintetében jó példa, hogy amíg a Radeon Image Sharpening le van tiltva a böngészőkön, mert nem túl jó az élmény vele, ha ezeket a tartalmakat élesíti, addig a Radeon Image Sharpening 2 működik itt is.

A fentieket akkor is érdemes figyelembe venni, ha valaki egy játékban használja a program saját élesítő eljárását. Utóbbi ugyan hasznos lehet, de a Radeon Image Sharpening 2 a szoftveres eljárásokra jellemző tipikus hibák nélkül jobb minőségű képet fog biztosítani. Azt viszont megjegyeznénk, hogy az új eljárás valószínűleg semmi olyat nem használ, ami ne lenne implementálható szoftveresen. Itt a probléma az erőforrásigény lehet, mivel egy komplexebb technikával valószínűleg nem csak 1%-ot lassulna a futtatási sebesség, ahogy az jellemző az eredeti Radeon Image Sharpeningre. Tehát nem kizárt, hogy a Radeon Image Sharpening 2 később szoftveres formában is elérhetővé válik, csak annak nagy ára lesz az általános teljesítményt tekintve, bár ez az RNDA 4-et a dedikált célhardvere miatt akkor sem fogja érinteni.

AMD Radeon RX 9070 VGA-k

Az RDNA 4 első körben két VGA-n debütál. A Radeon RX 9070 XT lesz a gyorsabb, míg a 9070 a lassabbik verzió. Mindkettő ugyanazt a Navi 48-as GPU-t használja, csak utóbbi esetében némelyik részegység le van tiltva, de a memória egységesen 16 GB-nyi kapacitást kínál.

[+]

Bár az AMD tervezett referenciamodelleket, ezeket csak az OEM partnereknek kínálják, így dobozos formában majd a gyártópartnerek megoldásait lehet megvásárolni. Ezek között számos eltérő alternatíva lesz, kifejezetten széles spektrumon alkalmazott gyári tuninggal, így sok modell közül lehet majd válogatni.

[+]

Két dolog van, amit az AMD igényel a gyártóktól: egyrészt a VGA-knak csendesen kell működnie, másrészt pedig a terhelés mellett alacsony üzemi hőmérséklet kiemelten szempont. Hogy ezekből mennyi valósul meg, az majd a következő héten derül ki.

Az új kártyák paramétereit az alábbi táblázat részletezi:

A kimenetek tekintetében a referenciamodelleken egy HDMI 2.1b és három DisplayPort 2.1a található. Ezt a konfigurációt ajánlja a gyártóknak is az AMD, noha ettől el lehet tőle térni.

[+]

A teljesítményt tekintve az AMD későbbi napra tette a független mérések megjelenését, de azt megengedte a cég, hogy a saját, Radeon RX 7900 GRE-hez mért adatait közzé lehessen tenni. Ezt a fenti négy képben meg is tettük, de különösebben nem elemeznénk a helyzetet, mert erre úgyis sor kerül a következő héten. Ekkor lényegében már minden adat hivatalos lesz, így bővebben is értekezhetünk az erősorrendről. Egyúttal érkezik még egy új AMD Software is, ami számos újítást kínál, erre is visszatérünk később, hogy ezeket részletesebben is be tudjuk mutatni.

Abu85