HBCC a gyakorlatban
Az AMD még az év elején leplezte le a Vega architektúrát, amelyről az alábbi írásban be is számoltunk. A leírtakat nem vesszük újra sorba, viszont a tegnapi Capsaicin & Cream előadáson volt pár újdonság, amiből a legfontosabb a HBCC, vagyis a High-Bandwith Cache Controller gyakorlati működése.
A HBCC ígérete nagyon ambiciózus volt. Az AMD már évek óta azt mondja, hogy a hagyományos VRAM-ra épülő modellben a VGA-n található fedélzeti tár kihasználása rendkívül alacsony. Ez egy iparágilag ismert probléma, csak senki sem tudta megoldani. A konzolok esetében kedvezőbb a helyzet, de az eleve fix hardver, és bizony nem várható el a PC-s fejlesztőktől, hogy minden egyes piacon kapható VGA-ra egyenként optimalizáljanak, mert úgy kvázi sosem készülne el a kiadandó program.
A rossz hatásfok azonban az utóbbi években kritikus tényezővé vált. Ma már nem ritka, hogy egy kifejezetten jól optimalizált játék is csak az 50%-át használja az adott VGA-ra helyezett VRAM-nak, és sajnos bőven előfordul 25%-os kihasználtság is. Ezek a számok igazából azt jelentik, hogy a VRAM tartalmának mekkora része hasznos adat, és mekkora területen van tulajdonképpen már nem használt információ, amelyek csak foglalják a helyet, de túl drága lenne törölni őket. Sajnos a DirectX 12 és a Vulkan API explicit kontrollja sem hozott ebben radikális előrelépést. A probléma itt már nem a rég nem használt adatok törlésére vonatkozik, hiszen ezek jóval kisebb többletterhelés mellett távolíthatók el, viszont teljes mértékben a program felel a memóriamenedzsmentért, ami távolról sem egyszerű feladat. Sajnos a fejlesztők azzal szembesülnek, hogy minden erőfeszítésük ellenére tele lesz szemetelve a VRAM nem lényeges adatokkal, így a kihasználtság hatásfoka DirectX 12 és Vulkan alatt sem megfelelő.
Az AMD a Vega architektúrával ezt a problémát hardveresen szeretné kezelni. A korábban alkalmazott, úgymond brute force módszer már nem tűnik kifizetődőnek, mert a memória drága és relatíve sokat fogyaszt, továbbá az explicit API-k terjedése miatt túlságosan sok függ a fejlesztőktől. Effektíve azt lehet mondani, hogy ha egy fejlesztő minimum 8 GB valós VRAM-kihasználással számol, ami a jövőben egy reális igény lehet, akkor a VGA-gyártóknak az a biztonságos, ha 32 GB VRAM-ot raknak a kártyákra. Ilyen esetben még a legrosszabb hatásfok mellett is lesz elengedő memória a sok nem használt, de betöltött adat mellett. Könnyen kitalálható, hogy ez miért nem realitás. Még a 16 GB VRAM elfogadható kompromisszum lenne, de fennáll a veszélye annak, hogy az adott program fejlesztője nem végez majd jó munkát. Márpedig a memóriamenedzsmentbe a DirectX 12 és a Vulkan API alatt a grafikus meghajtó nem tud beleszólni, tehát a hardver is arra az esetlegesen nem túl jó minőségű kódra van kényszerítve, amelyet az adott alkotáson belül szállítottak.
Az AMD éppen ezért a Vega architektúránál csak annyit kér a fejlesztőktől, hogy adják meg a betöltendő adatokat, és ne csináljanak semmi mást, mert a hardver jobb munkát fog végezni. Ez a fejlesztők számára reális kérés, hiszen DirectX 12 és Vulkan API-val ez csupán pár sor beírását igényli, míg a régebbi OpenGL és DirectX verziókkal erre sincs szükség, ugyanis az eszközillesztő automatikusan képes aktiválni a HBCC-t, a program oldalán semmiféle beavatkozásra nincs szükség. Emellett persze a többi architektúrához mindenképpen kell a DirectX 12 és a Vulkan API alatt valamilyen memóriamenedzsment, de a Vega architektúrát ennek az esetlegesen rossz hatékonysága már nem fogja érinteni. Ezzel az AMD szeretné magát függetleníteni az emberi tényezőtől, ami eleve rendkívül kiszámíthatatlan.
A HBCC azonban eddig csak ígéret volt, és az AMD nem mutatta meg soha, hogy mennyire működik hatékonyan. Raja Koduri a tegnapi előadáson kijelentette, hogy a Vega memóriamodellje 100%-os hatékonysággal működik, vagyis a HBC-be, azaz az úgynevezett High-Bandwith Cache-be kerülő összes adat hasznos, és ha már nincs szükség ezek közül valamelyikre, akkor automatikusan törlésre kerül, és a felszabaduló területre más adatok kerülnek. Ez alapvetően nem különbözik sokban attól, amit ma egy modern grafikus motor csinál, hiszen az ezekbe épített streaming rendszer alapvetően a rendszermemóriát használja amolyan bástyaként, és tulajdonképpen innen kerülnek át a szükséges adatok a VRAM-ba. Amíg azonban ezt egy szoftveres modul végzi az aktuális rendszereken, addig a Vega architektúránál maga a hardver gondoskodik az egész folyamatról. Utóbbi előnye, hogy lényegesen gyorsabban tud reagálni az egyes igényekre, illetve az adatok törlésének és betöltésének sincs semmilyen többletterhelése, nem beszélve az emberi tényező kizárásáról.
Az AMD a Deus Ex: Mankind Divided játékban mutatta be a HBCC működését. Erről köztudott, hogy alapvetően 4 GB VRAM-hoz optimalizálták, de igazából nem árt neki, ha több fedélzeti tár van az adott VGA-n. Ami viszont biztos, hogy 2 GB VRAM-mal igen dadogósan fut, mivel ennyi memória már nem elég neki a maximális részletességhez. Ez tökéletes alap volt az AMD-nek ahhoz, hogy két konfiguráción összehasonlítsák a HBCC-t. Mindkét gépben egy Vega architektúrára épülő GPU volt, amin a fedélzeti memória kapacitását mesterségesen 2 GB-ra korlátozták. Az egyik rendszeren a HBCC ki volt kapcsolva, tehát a hagyományos VRAM modell működött, míg a másik gépen belül a HBCC aktív volt. Előbbi esetben nem okozott meglepetést, hogy a 2 GB VRAM kevésnek bizonyult, hiszen nem erre tervezték magát a játékot, a HBCC móddal viszont ennyi fedélzeti tár is elég volt, és 50%-ot gyorsult az átlag teljesítmény, valamint 100%-ot a minimum fps.
A fenti teszt persze mesterségesen kialakított körülmény, ami csupán a HBCC gyakorlati hatékonyságát hivatott igazolni. Ha mondjuk nem lett volna 2 GB-ra korlátozva a fedélzeti tár, akkor a hagyományos és a HBCC mód nagyjából ugyanarra a teljesítményre lett volna képes. Viszont a Vega memóriamodelljével az AMD azt szeretné elérni, hogy a fejlesztők hozzák a mostaninál nagyobb felbontású textúrákat, ezekre ugyanis a 4K miatt szükség lenne. A legtöbb programnál a megfelelő tartalmat eleve elkészítik, de kiadás előtt nem biztos, hogy az adott játékot az elérhető legjobb minőségű tartalommal szállítják. Ennek jellemzően egy oka van: nem bírná el az aktuálisan megépíthető legjobb konfiguráció. A miértre adott válasz persze nem egyértelmű. Lehet, hogy kevés a VRAM, vagy nem elég jó a programhoz írt, illetve a meghajtókban dolgozó memóriamenedzsment, esetleg mindkettő. A Vega memóriamodellje ezen annyit változtat, hogy tulajdonképpen leszállíthatóvá teszi az elkészített legjobb minőségű tartalmat. Ez nem fog futni minden hardveren, de kiadható lehet egy külön Vegához tervezett textúracsomagként, ami végeredményben kedvező a fejlesztőknek, mivel eleve kész tartalomról van szó. Valószínűleg az AMD a partnereivel dolgozni fog ilyen lehetőségeken, hiszen most már a fedélzeti tár kihasználásának hatásfoka nem lehet akadály.
A cikk még nem ért véget, kérlek, lapozz!