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 cikk még nem ért véget, kérlek, lapozz!
