Az AMD a normál és a professzionális Vega VGA-kat is bemutatta

Dióhéjban a HBCC

Az AMD az ígérteknek megfelelően a SIGGRAPH rendezvényen mutatta be a játékosoknak és a professzionális piac számára készült, Vega 10-es GPU-t használó VGA-kat. Eddig csak a félprofesszionálás piacnak való Frontier Edition volt elérhető, de augusztus és szeptember közepétől ez megváltozik. Az új rendszerről az alábbi írásban már korábban beszámoltunk, illetve a Capsaicin & Cream előadáson is előkerült pár friss adat, amiből a legfontosabb a HBCC, vagyis a High-Bandwith Cache Controller gyakorlati működése.

27 GB-nyi adat, félmilliárd háromszöggel nem jelent problémát a Vega 10 HBCC-jének. [+]

A HBCC-t emelte ki ezúttal is az AMD, ugyanis ez az egyik legnagyobb frissítés, amióta a GPU-k léteznek. Szükség is volt rá, mivel a tradicionális VRAM modellel több baj is van. Egyrészt nem igazodik direkten a host processzor laptáblájához, így teljes allokációk ugyan másolhatók a rendszermemóriából a VRAM-ba, de maguk a lapok önmagukban nem. Ez nagymértékű pazarlást jelent a VRAM oldalán, ugyanis ha egy nagy allokációból csak kevés adat kell, akkor a teljes allokációt be kell másolni, bármennyire is szükségtelen a tárolt információ akár 99%-a. Ez magával hozza azt a problémát, hogy a VRAM menedzsmentje a szoftveres oldalt tekintve rendkívül nehézzé válik a fejlesztők vagy a meghajtók számára (API-tól függően), hiszen hiába kell csak a VRAM-ban tarolt adatok jellemzően 25-45%-a, ehhez rendkívül méretes allokációkat kell másolgatni a VRAM és a rendszermemória között. Ráadásul a nem használ allokációk törlése nincs is ingyen, ugyanis a DirectX 11 vagy régebbi, illetve az OpenGL API-t használó játékok esetében a meghajtónak rengeteg ellenőrzést kell ahhoz elvégezni, hogy memóriaterületet szabadítson fel, és ehhez csak végszükség esetén nyúlnak, mivel biztosan akadás lesz az eredménye a programfuttatás során. Hasonlóan kellemetlen lehet a helyzet DirectX 12 és Vulkan API esetén is egy rosszul felépített memóriamenedzsmenttel, amire többször is láthattunk már példát az eddig megjelent explicit API-t használó játékoknál.

A fentieket egyébként több probléma is okozza. A DirectX 12 és a Vulkan API-tól sokan változást reméltek, és elvi szinten ezekre lehet is sokkal hatékonyabb memóriamenedzsmentet írni, mint amire egy grafikus meghajtó valaha is képes lesz, de a SIGGRAPH-on kiderült, hogy ez PC-n nem olyan egyszerű. A legtöbb fejlesztő a konzolokra írt menedzsmentet próbálja áthozni PC-re, de ezt nem lehet csak úgy egy az egyben megtenni, ugyanis a PC esetében az operációs rendszer két folyamattal menedzseli a memóriát: az egyik csak a CPU által elérhető rendszermemóriáért felel, míg a másik a videomemóriáért, illetve a CPU és a GPU számára is hozzáférhető rendszermemóriáért. Konzolon ugyanakkor direkt vezérlést is lehet kérni, vagyis igényelhető az operációs rendszertől, hogy adja oda a programnak a memóriát, és semmiféle háttérfolyamattal ne menedzselje azt. Ilyenkor a program biztosít minden olyan feladatot, amit PC-n például az operációs rendszer láthat csak el. A legtöbb fejlesztő ezt a formát választja nagymértékű hatékonysága miatt, ugyanakkor ezt portolni a PC-re már nagyon is nehézkes lehet, mivel az operációs rendszer menedzsmentfolyamatai sok esetben nem úgy működnek, ahogy a programba épített konstrukció. Szóval explicit API ide vagy oda, az alapprobléma nem tűnt el, csak átalakult.

Ami a játékoknál megfigyelhető, hogy az elmúlt időszakban eszméletlenül megnőtt a VRAM-ra vonatkozó igényük. Kis túlzással az egyik pillanatban még el lehetett lenni egy 2 GB-os VGA-val, míg a másikban már hirtelen értelmet nyertek a 8 GB-os megoldások. Ez nem azért történt, mert annyira robbanásszerű ugrást élt meg a grafika minősége, hogy gyorsan kellett a memória négyszerese, hanem sokkal inkább a rossz hatásfokra vezethető vissza. Minél komplexebb ugyanis egy program, annál nehezebb ezt kontrollálni. Az is kiderült, hogy elméletben nem lenne gond, ha PC-n is megkaphatná az alkalmazás a memóriamenedzsment teljes kontrollját, de ez teljességgel használhatatlan ötlet, mert megszámlálhatatlanul sok hardveres memóriakonfigurációt kellene lefedni, és erre a fejlesztők képtelenek lennének. A menedzsmentet részben tehát az operációs rendszer kezében kell tartani, hogy valami el tudja fedni a konfigurációk közötti különbséget.

Az AMD szerint ugyanakkor a probléma jelentős. Amikor a videomemória háromnegyede nem használt adattal van tele, akkor el kell gondolkodni rajta, hogy a működést biztosító rendszer nem rossz-e. Már csak azért is, mert igen rövid időn belül 32-64 GB-os VGA-kat kellene tervezni a rossz hatékonyság elfedésére, és a memória által igényelt fogyasztás a GPU TDP keretét fogja csökkenteni.

[+]

A vállalat megoldása a problémára a HBCC, vagyis a High-Bandwith Cache Controller. Ez a rendszer bevezeti a lapalapú memóriamenedzsmentet, vagyis ahelyett, hogy a VRAM-ba a teljes allokációt bemásolná a program vagy a meghajtó, elég csak azokat a lapokat kiválasztani, amelyeket a program valóban használni is fog. Ez a finomszemcsés adatmozgatás lényegében lehetővé teszi, hogy a videomemóriában csak az aktív lapok legyenek, míg az inaktívak visszakerülnek a rendszermemóriába. Ráadásul ezt a folyamatot teljesen a hardver vezérli, vagyis a fejlesztőktől semmilyen szoftveroldali menedzsmentet nem szükséges hozzá. A fenti változás miatt az AMD a VRAM-ot mostantól HBC-nek, azaz High-Bandwith Cache-nek nevezi.

A HBCC több problémát old meg egyszerre. Egyrészt a HBC-ben, vagyis a videomemóriában többet nem alakulhat ki jelentős töredezettség, a lapméretek ugyanis egységesek (4 és 64 kB). Ezáltal a GPU melletti fedélzeti tár majdnem 100%-a hasznosítható, ami elég nagy ugrás a korábban jellemző 25-45%-os arányhoz képest. Másrészt a rendszer nincs kitéve a szoftveres menedzsment problémáinak sem. Elképzelhető, hogy a jövőben is lesznek olyan explicit API-t használó címek, ahol a memóriamenedzsment nem működik a várt módon, és ez komolyabb akadásokhoz, illetve lassulásokhoz vezet, de a Vega architektúrára épülő GPU-k erre teljesen immunisak. Harmadrészt a videomemóriából való törlés mostantól nem jár többletterheléssel. Az inaktív lapok eltávolítását a hardver végzi, és nem kéri hozzá az operációs rendszer engedélyét, vagyis az eltávolításhoz szükséges temérdek ellenőrzési folyamatot is megússza. Ez azért lényeges, mert ezzel a modellel egy program, ezen belül is egy játék soha többet nem fog megakadni a memóriatörlés miatt. Negyedrészt pedig elérhetővé válik az olyan méretű adatmennyiséggel való munka, amilyet korábban nem lehetett alkalmazni a rendszerben megbúvó korlátok miatt. Az AMD szerint ezzel nagyobb részletességű modellekkel és magasabb felbontású textúrákkal dolgozó, nyílt világú játékokat láthatunk lényegében töltőképernyők nélkül.

A hardver oldaláról egyébként a HBCC áll magából a vezérlőből, illetve a multiprocesszorokba épített címfordítókból. Előbbi blokk- és bájtszintű információkat is tud kezelni, vagyis a rendszermemória mellett esetlegesen az adattárolókat is el tudja érni, míg a címfordító folyamat az x86/AMD64 utasításarchitektúrájú processzorokkal kompatibilis, vagyis ilyen host CPU-t kell alkalmazni, hogy a HBCC üzemképes legyen. A címezhető virtuális memória maximális mérete egyébként 512 TB.

A HBCC kétféle módban üzemképes. Az egyik az exkluzív cache mód, ahol tulajdonképpen a HBCC szegmens a teljes HBC és a rendszermemória egy része lesz. A másik az inkluzív cache mód, aminél egy hierarchikus lapozás lép életbe. Utóbbi a megjelenéskor nem lesz elérhető, így egy későbbi frissítés teheti majd használhatóvá, de a hardver képes rá.

A meghajtó oldalán egyébként ki-/bekapcsolható a HBCC, és aktív állapotban megválasztható a memória kapacitása is, ami maximum 64 GB lehet. Jelenleg alapértelmezetten inaktív, ugyanis több programban sem tökéletes még a működése, de később ez meg fog változni. Már csak azért is éri meg alapértelmezetten aktívvá tenni, mert előnyt is tud biztosítani, például a Unigine Heaven tesztprogramban plusz 7%-ot.

A Vega 10 részletesebben

A Vega 10 kódnevű GPU-n belüli további képességeket is kifejtette az AMD. Ezek már bemutatott újítások, csak éppen részletesebben tárgyalva.

A packed math ismert lehet egy ideje, a GCN3 és a GCN4 architektúra is támogatja, viszont a GCN5-öt használó Vega 10 további fejlesztéseket tartalmaz. Itt tulajdonképpen arról van szó, hogy milyen adatokkal dolgozik a program. Jelenleg jellemzők a 32 bites nem csomagolt adatok, amelyekkel a vektorregiszterekre vonatkozó terhelés tulajdonképpen teljes lesz, és ez nem igazán jó, mivel sok shader esetében a nagyobb pontosságnak nincs lényegi haszna, viszont a kihasználtságra vonatkozó limittel rendelkező SIMT architektúráknak (ilyen a GCN is) az egész szituáció nem kedvez. Az AMD a megoldást kétféle csomagolási stratégiában látja, amelyek struktúrák tömbje, illetve tömbök struktúrája néven ismertek. A GCN3 és GCN4 hardvereken mindkettő a felére csökkenti a vektorregiszterekre vonatkozó terhelést, így a kihasználtságra vonatkozó limit csökken, vagyis az újabb verziójú GCN dizájnok esetlegesen több wavefrontot futtathatnak a multiprocesszoron.

[+]

A Vega esetében már nem csak a vektorregiszterek terhelése lesz visszafogva, hanem konkrétan nő az operációk végrehajtásának tempója. Elméleti szinten ez a struktúrák tömbje opciónál 50%-kal jobb sebességet eredményez, míg a tömbök struktúrája verzió konkrétan a duplájára gyorsítja a feldolgozást.

Az AMD arra számít, hogy ez egy vezető irányzat lesz a közeljövőben, köszönhetően annak, hogy az aktuális explicit API-k már támogatják, és elég komoly teljesítményt lehet vele nyerni. A Futuremark már dolgozik is egy példának tekinthető tesztprogramon, amely Serra kódnévre hallgat. Ebben az AMD állítása szerint jelentősen növeli a teljesítményt a packed math a normál precizitáshoz képest, miközben a képminőségre vonatkozóan nincs látható negatív hatása.

A primitive shader is újra előkerült, mivel a háromszögek optimális feldolgozása is szükséges a jó grafikai eredményhez. Az AMD szerint ugyanakkor a geometriai motorok számának növelésével nem lehet sokat nyerni. A probléma pont az, hogy rendszerszinten keletkezik a limitáció, vagyis attól, hogy több a feldolgozó, a limiteket még húzzuk magunkkal. Ez tulajdonképpen egy hasonló hatékonysági probléma, mint a VRAM esetében az allokációk kezelése, persze nyilván más a gond jellege. Jelen esetben az a baj, hogy hiába dolgozik a motor komoly kivágási technikákkal, hiába van sok feldolgozó a hardverben, a geometria komplexitásának növelésével egyre több olyan háromszög lesz kivághatatlan, amelyekről csak a raszterizálás után derül ki, hogy nem látszik. A probléma ráadásul a modellek és a világ részletességének növelésével exponenciálisan válik egyre súlyosabbá.

[+]

Az AMD szerint az lenne az ideális, ha a raszterizálóig már eleve csak egy minimális számú nem látható háromszög jutna el. Emiatt vezeti be a cég a primitive shadert, ami az aktuális futószalagokba több szempontból is becsatlakoztatható. Egyrészt ki tudja váltani a vertex, domain és geometry shadert, de akár ki is egészítheti ezeket, ez teljes mértékben a programfejlesztő döntése. A lényeg az, hogy ezzel az új shader lépcsővel már a futószalag elején meg lehet mondani rengeteg primitívről, hogy nem látszanak, így nem kell teljesen felesleges számításokkal terhelni a hardvert a raszterizálóig. Emellett számos esetben a primitive shader képes jelentősen gyorsítani a feldolgozást, így az árnyéktérképekhez, illetve a részecskeeffektekhez kifejezetten jól jöhet, de a VR szempontjából fontos leképzési technikák hatékonyabb megvalósításában is segíthet.

[+]

A nyers számok tekintetében a Vega 10 a korábbi csúcsnak számító, Fiji kódnevű GPU-hoz viszonyítva nagyjából kétszeresére növeli a primitív-feldolgozó képességet, holott ugyanannyi geometriai motor van benne. Ez főleg annak köszönhető, hogy a Fiji még nem rendelkezett Primitive Discard Accelerator egységgel, ami ugye a Polaris generációban mutatkozott be, és ez a degeneratív háromszögeket kivágja. Utóbbiak olyan háromszögek, amelyeknek mindhárom csúcsuk egy egyenesre esik. Az igazán ütős eredményre az új mód ad lehetőséget, amely majdnem hétszeresére növeli a Fijihez képest az előnyt, és ahogy említettük, a Vega 10-ben fizikailag nincs több geometriai motor. Ez jól mutatja, hogy komplex geometria mellett nem a feldolgozók számával lehet sokat nyerni, hanem a jelenlegi feldolgozási modell megreformálásával, ezen belül is a limitációk és a gondok direkt kezelésével. A primitive shader megjelenéskor nem lesz elérhető, így csak egy későbbi frissítés teheti használhatóvá, de az AMD már teszteli a funkciót, így idővel be fogják építeni.

Az új pixelmotor is kapott némi figyelmet. Ebből a szempontból már régóta ismert, hogy a Vega 10 bevezet egy új raszterizálót (draw stream binning rasterizer), amely a mozaikos optimalizálás mellett a PowerVR GPU IP-k speciális funkciói felé is tesz egy lépést a draw stream miatt. Utóbbi lényegében egy listát generál az adott mozaikhoz tartozó primitívekről és rajzolási parancsokról, amivel a Vega képes párhuzamosítani a raszterizációt, így az egész feldolgozás hatékonyabban hajtható végre. Ezt a módot a meghajtó kapcsolja be, tehát előfordulhat, hogy az egyes játékokban aktív az új raszterizáló, míg más játékokban legacy módban működik a harver, ami lényegében megfelel a Fiji GPU-nak. Amennyiben aktív a friss raszterizálási mód, akkor az lényegében csökkenti a videomemóriába kiírt adatokat, vagyis a lapkán belül tartja a mozaikok feldolgozását. Ez amellett növeli a teljesítményt, hogy közben csökkenti a memóriabusz terhelését, ezáltal pedig csökken a fogyasztás is.

[+]

Az új raszterizálási mód a nyers számok alapján legalább kétszer hatékonyabb a legacy módnál, és az egyes játékokban 3-33% között csökkenti a képkockánkénti, fedélzeti tárba kiírt bájtok számát.

Maga a Vega 10

Az ismert újítások részletesebb magyarázata után magáról a lapkáról is érdemes szót ejteni. A Vega 10 egy 484 mm²-es kiterjedésű fejlesztés, ami a GlobalFoundries 14 nm-es LPP node-ján készül. Benne 12,5 milliárd tranzisztor található, míg 2048 bites memóriabuszához két HBM2 memória kapcsolódik. Utóbbi konfigurációval a kapacitás lehet 8 vagy 16 GB.

A lapkán belül 64 darab NCU (Next-Gen Compute Unit), azaz multiprocesszor található, ami 4096 shader feldolgozót és 256 textúrázócsatornát jelent, illetve a blending egységek száma 64 lesz. Ezek mostantól a 4 MB-os L2 gyorsítótár kliensei, így a textúrába való leképezés cache flush nélkül is megoldható. Az ACE-ek száma négy lesz, ami csökkenést jelent a korábbi generációkhoz képest, de ezek a parancsmotorok teljesen újak, így jóval hatékonyabban is dolgoznak, illetve mindegyik biztosít QoS támogatást a teljes hardverre nézve, vagyis a GPU mellett az UVD és a VCE is virtualizálható, ráadásul automatikus hardveres ütemezés mellett. Ezt egészíti ki az AMD Secure Processor, ami lehetővé teszi a biztonságos memóriazóna támogatását, illetve a validált firmware-t és a hardveresen validált bootolást.

[+]

A kijelzőmotor is fejlődött, amit az alábbi kép bővebben részletez:

[+]

Fontos lépcsőnek számít, hogy képességek tekintetében a Vega 10 az első dedikált GPU, amely támogatja a DirectX 12 összes funkcióját, illetve az év végén érkező shader modell 6.0 esetében is megfelel az összes tervezett opcionális követelménynek, továbbá a shader modell 6.1 újításait is támogatni fogja. Technikailag a rendszert az AMD igen átfogóra tervezte, így számos olyan képességgel rendelkezik még, amelyet nem vagy csak nemrég adtak le szabványosításra. A fő cél a primitive shader elterjesztése lehet, ugyanis ha valaha is szeretnénk rendkívül részletes világot, akkor ki kell ütni a rendszerből azokat a limitációkat, amelyek ennek a létrehozását gátolják.

Az AMD továbbra is épít majd a GPUOpen Shader Intrinsic Functions gyűjtőnéven ismert extrákra, amelyek segítenek a fejlesztőknek elérni a Vega 10 szabványosan nem hozzáférhető képességeit. A vállalat kiemelte, hogy ezek komoly teljesítményelőnyt biztosíthatnak, és ez nem csak elmélet, mivel az ID Software a Doom Vulkan API-t használó módjába átemelte a PlayStation 4-re vonatkozó optimalizálást, ami végül 43%-kal növelte meg a GCN-es Radeonok teljesítményét.

A jövőben több fejlesztővel is együttműködnek majd, hogy kihasználják a Vega 10 újításait. Többek között a Quake Champions, a Wolfenstein II: The New Colossus, a The Evil Within 2 és a Far Cry 5 biztosan ilyen cím lesz. Ezen belül is kiderült, hogy a Wolfenstein II: The New Colossus elsődlegesen a packed math-t veti majd be, míg a Far Cry 5 esetében a packed math mellett a HBCC-t is csúcsra akarják majd járatni. Általánosan elmondható még, hogy az említett játékok mindegyike használ majd aszinkron compute-ot, illetve specifikus GPUOpen shader kiterjesztéseket. A keleti piac is kap némi szeretetet, ugyanis a Ni Shui Han című MMORPG-be beépül a packed math támogatással rendelkező, legújabb TressFX verzió, illetve a fejlesztők ezt a funkciót volumetrikus köd effektjükhöz is felhasználták.

Az órajelet tekintve a Vega architektúrát már nagy teljesítményűre tervezte az AMD, így 1,7 GHz-es órajelet is be lehet állítani. A négy fokozat mélységű ALU-k nem változtak, viszont az NCU-k esetében már nem négy, hanem csak maximum három alkothat egy tömböt, ami segít az említett órajel elérésében. A korábbi belső összeköttetést felváltotta a Ryzennél már megismert Infinity Fabric, ami dedikált órajelen üzemel, továbbá energiatakarékossági fejlesztés, hogy deep sleep módban a rendszer a második statikus órajel-generátorra válthat, illetve a HBM2 memóriáknak is lett egy alacsony órajelű módja.

Az érkező VGA-k

A technikai alapok után az AMD a termékeket is bejelentette. A játékosok számára az egységesen 8 GB HBM2 memóriával felszerelt Radeon RX Vega sorozat augusztus 14-étől lesz elérhető, kivéve a legkisebb VGA-t, amire 28-áig várni kell. A csúcsmodell a Radeon RX Vega 64 Liquid Cooled Edition lesz, ami nevének megfelelően vízhűtést használ. Ennek lesz egy levegőhűtéses verziója, limitált sorozatú, metál színezésű felülettel. Ezek lesznek a drága modellek 549 és 649 dollár közötti árral.

Radeon RX Vega VGA-k, különleges dizájnnal [+]

A normál Radeon RX Vega 64 499 dollár lesz, kevésbé szép hűtővel, de a funkcióját ellátja majd ez is, illetve 399 dollárért érkezik egy Radeon RX Vega 56 is, aminél 8 multiprocesszor letiltásra kerül.

A háromféle Radeon RX Vega verzió eddig ismert paramétereit az alábbi táblázat részletezi:

A játékosok számára azonban érdekesek lehetnek az AMD pakkjai. Ezek 200 dolláros árcsökkentést biztosítanak a FreeSync technológiát is támogató 34 hüvelykes Samsung CF791-es monitorra, illetve 100 dollárral megvágják a Ryzen 7 1700X vagy 1800X CPU-k és egy kijelölt X370-es alaplap (ASUS ROG Crosshair VI Extreme X370, Gigabyte GA-AX370-Gaming K7, illetve MSI X370 XPOWER Gaming Titanium) árát. Emellett bizonyos régiókban elérhető lesz a Wolfenstein II: The New Colossus és a Prey című játékhoz tartozó, ingyenes letöltést biztosító kupon is. Ezzel összességében 420 dollár kiadás spórolható meg.

Fentiek a Radeon Red, Black és Aqua Packben érhetők el, rendre 499, 599 és 699 dollárért, és a csomagok része lesz egy Radeon RX Vega 56, egy Radeon RX Vega 64 normál és egy Radeon RX Vega 64 vízhűtéses kiadás. A Vega tehát csomagban sokkal olcsóbb, bár itt az AMD elsődlegesen egy lazább árukapcsolást szeretne megvalósítani.

A professzionális piacra szánt Radeon Pro sorozat is kap két új VGA-t, de csak szeptember 13-ától. Az egyik újdonság itt a Radeon Pro WX9100 lesz, ami lényegében egy Radeon Vega Frontier Edition modell, csak éppen certifikált meghajtókkal, és emiatt sokkal drágább is lesz, valahol 2000-2500 dollár környékén áll majd meg az ára. Ráadásul ezen már ECC-t is támogat a 16 GB HBM2 memória.

AMD Radeon Pro SSG és WX9100 [+]

Az igazi nyalánkság az első, piaci elérhetőségre szánt Radeon Pro SSG lesz, ami tulajdonképpen a Vega 10-et a 16 GB-nyi HBM2 mellett kiegészíti még 2 TB SSD-vel is. Ezt az AMD kifejezetten a 8K-s videók valós idejű szerkesztésére szánja, ahol rendkívül fontos, hogy legyen kellő mennyiségű fedélzeti tár a GPU-hoz közel, különben a folyamatosságnak lőttek. Ennek a terméknek az ára 7000 dollár lesz.

További fontos adalék a professzionális piac szempontjából, hogy az AMD megnyitotta Radeon ProRender forráskódját, így az mostantól elérhető az alábbi GitHub oldalon.

A további specifikációkat az AMD a fentebb említett dátumok során fedi fel, amikor megtörténik a tényleges start.

Abu85