A memóriamenedzsment problémája

Az előző oldal alapján a lapka felépítéséről kialakulhatott egy általános kép, ami azért volt fontos, mert a korábban megemlített problémákat és annak AMD által kialakított megoldásait csak így lehet igazán megérteni.

Elsőként említettük a memóriamenedzsment hatásfokát, mint gondot, ami furcsamód igen sokáig nem igazán jelentett problémát, de a helyzet határozottan súlyosbodik. Először is érdemes kiemelni, hogy a videomemóriát ma igen sokan félreértik. A valóságban a programfuttatás nem olyan egyszerű, hogy a töltőképernyő alatt az adott alkalmazás majd bemásolja a szükséges adatokat a GPU melletti fedélzeti tárba, és ezzel kész is. Igen jelentős munka van mögötte, hogy ez az egész rendszer egyáltalán működjön, és ebben részt vesz maga az operációs rendszer, a grafikus meghajtó, illetve a program is. Persze az alkalmazott API-tól függően az egyes modulok feladatai eltérőek, például a DirectX 11 esetében nagyrészt a grafikus meghajtó felel a menedzsmentért, míg DirectX 12 API mellett ez inkább a programra hárul, és a meghajtó feladata lényegében kimerül a GPU virtuális címtartományának kezelésében.

A lényeg nem is ez, mivel akármilyen API-n is fut a program, nagyjából ugyanaz történik meg, csak éppenséggel más szinten. Ezt érdemes külön kiemelni, mert jól jelzi, hogy mennyire gyorsan változik az iparág véleménye az egyes problémákról. Nem is olyan régen még az volt az általános álláspont, hogy az a legjobb, ha a program nem próbálja meg maga menedzselni a memóriát, ezt a feladatot ugyanis a kernel módban futó grafikus meghajtó jobban el tudja végezni. Mára ez gyökeresen megváltozott, meglepő módon olyannyira, hogy a DirectX 12-ből konkrétan el is tűnt a kernel módban futó grafikus meghajtó, vagyis alig fél évtized leforgása alatt az egész iparág csinált egy komplett hátraarcot. Hogy jól tette-e? Nos, az eddigi gyakorlati példák alapján, legalább nem lett rosszabb, és ezzel mindent leírtunk.

Magát a problémát kifejtve arról van szó, hogy egy PC-ben nem csak egyféle memória van. Ha csak rendszermemória lenne és minden onnan működhetne, akkor az maga lenne a Kánaán, de ennél jóval komplexebb egy személyi számítógép. Az újabb Windowsokon a rendszermemóriának van egy csak processzor által elért része, és egy olyan területe is, amihez a processzor és a grafikus vezérlő is hozzáfér, végül van a grafikus vezérlő fedélzeti tárja, ami az operációs rendszer nézőpontjából eléggé elszigetelt memória, és a processzor nem is férhet hozzá. Itt igazából az a terület az érdekes, amit a processzor és a grafikus vezérlő is elér, ráadásul egy különálló szervizfolyamat menedzsel (API-tól függően ez származhat az operációs rendszerből vagy a grafikus meghajtóból). Amikor tehát egy modern rendszeren fut egy alkalmazás, akkor nem csak a videomemóriába tölti a GPU számára szükséges adatokat, hanem a rendszermemória egy részébe is.

Ez a konfiguráció több dolgot kezel. Egyrészt vannak olyan erőforrások, amelyekhez hozzá kell férnie a processzornak is, és vannak olyanok, amelyeket elég, ha csak a grafikus vezérlő lát. Másrészt alapvető működési formának számít manapság a tartalom úgynevezett streamelése, vagyis elég ha az az adat van a videomemóriában, ami feltétlenül szükséges, és a többi nyugodtan tanyázhat a rendszermemóriában. A nehézséget igazából az adja, hogy legyen egy megfelelő stratégia az adatok hatékony streamelésére, és a ragyogó elmélet itt szokott bukni.

A streameléssel ugyanis előbb-utóbb telítődik a videomemória, vagyis bizonyos időközönként a nem használt allokációkat törölni kell. Ez azért nagyon fájó dolog, mert például DirectX 11-ben nem lehet ezektől csak úgy megszabadulni, hanem egy igen komoly többletterhelést generáló ellenőrzési procedúrán keresztül a processzor sorra veszi az összes feldolgozás előtt álló rajzolási folyamatot, hogy ellenőrizze, a törölni kívánt allokáció kell-e valamelyiknek. Az esetek nagyon nagy többségében az fog kiderülni, hogy nem, és az allokáció már törölhető is, de olyan hosszú volt az ellenőrzés, hogy a felhasználó biztosan látni fog egy akadást. A DirectX 12-ben pontosan emiatt került a program keze alá ez a folyamat, ugyanis az alkalmazás tulajdonképpen kitörölheti a nem használt allokációt a videomemóriából anélkül, hogy ellenőrizné a szükségességét, vagyis az akadástól mentesülhet a felhasználó. Ebben az a kockázat, hogy ha mégis szüksége volt rá egy GPU-ba már bejutott rajzolási folyamatnak, akkor az egy nagyon kellemetlen programösszeomlást fog eredményezni. Szerencsére az explicit API-khoz tartoznak különböző eszközök, amelyekkel jól fel lehet készíteni a programfuttatást.

A cikk még nem ért véget, kérlek, lapozz!