A hardver optimális vezérlése
Természetesen a shader fordítás optimalizálása és a kódok cseréje csak az egyik fontos tényező, mivel a grafikus meghajtónak más feladata is van. Ezek közül kiemelten fontosnak tekinthető az állapotváltások szűrése, a hazárdok kezelése és a videomemória menedzselése.
Az állapotváltások szempontjából a mai működési modellben igen nagy problémák vannak. Erről az alábbi oldalon részletesen írtunk, így ezt nem ismételjük meg, de fontos adalék az állapotváltások szűrése, mivel ezek sok processzoridőt igényelnek. A legjobb, ha már maga a program törekszik az állapotváltások minimalizálására. Ezt egyszerűen meg lehet tenni a jelenet tartalmának állapotadatok szerinti csoportosításával, ami jó alapot ad arra, hogy az azonos állapotot igénylő feladatok lehetőség szerint állapotváltás nélkül, egymás után fussanak le. Ezt szűri a legtöbb grafikus meghajtó is, mivel számos program nem figyel erre, pedig nagyon lényeges elemről van szó a potenciális tempóelőny szempontjából. Ugyanakkor sok fejlesztő bosszús miatta, hiszen az állapotváltások szűrését sokszor megcsinálja a program, bizonyos beállításokkal megcsinálja az API és végül a grafikus meghajtó is, vagyis rossz esetben ugyanarra a feladatra háromszor annyi processzoridőt használnak, mint kellenne. Viszont a gyártók szerint a programok nagy részét tekintve így is ez adja a legjobb eredményt, mivel a grafikus meghajtó erre vonatkozóan annyira optimalizálva van, hogy sokszor a programba épített szűrésen is javít.
A hazárdok kezelése szintén kulcsfontosságú, és erre nagy hangsúlyt fektetnek a grafikus meghajtók rendszerprogramozói. Alapvetően egy olyan rendellenes működésről van szó a programfuttatás során, amely valamilyen úgynevezett adatfüggőséget okoz. Többféle formája létezik. Írás utáni olvasásfüggőségről akkor beszélünk, ha egy utasítás olyan adatot szeretne kiolvasni a memóriából, amely esetleg még nem áll rendelkezésre. Írás utáni írásfüggőség akkor alakul ki, ha két egymás utáni utasítás ugyanabba a memóriacellába akar írni, de az első utasítás ezt még nem tette meg, így azt meg kell várni. Végül az olvasás utáni írásfüggőség az a jelenség, amikor egy utasítás éppen kiír egy adatot egy olyan memóriacellába, amelynek a tartalmát egy korábbi feladat éppen olvassa, tehát az írás nem hajtható végre. Mivel a magas szintű hardvereléréssel a grafikus vezérlő jelentős része gyakorlatilag el van zárva a programozó elől, így minden ilyen szituációt a grafikus meghajtónak kell kezelnie, abszolút hibamentesen és teljesen általánosan. A legnagyobb gond ezzel a modellel, hogy nem párhuzamosítható operációkról van szó, és a fejlesztőknek semmilyen kontrolljuk sincs felette.
Végül a videomemória menedzselése kritikus fontosságú, mivel a rendszermemóriával ellentétben ezt az adott program nem látja. Messze ez a legnagyobb gátja az új technikák fejlesztésének, mivel a programozó igazából pufferek kreálására (és törlésére) utasítja a rendszert, és a videomemóriában való tényleges bűvészkedést a grafikus meghajtó oldja meg a WDDM-en (Windows Display Driver Model) keresztül. Itt történik a legtöbb optimalizálás a gyártók rendszerprogramozói részéről, mivel a hardverek memóriamodellje még azonos architektúrán belül is sűrűn megváltozik, vagyis az új lapkákhoz új menedzselés is kell.
A DirectX 11 hardverelérési modellje [+]
A grafikus meghajtók minden kicsit is eltérő memóriamodellel rendelkező grafikus architektúrához tartalmaznak megfelelő vezérlési formát, így az eszközillesztő mondja meg a hardvernek, hogy milyen lesz a program által igényel pufferek allokációja, amely egyébként függhet a beállított felbontástól és a grafikus vezérlő rendelkezésére álló videomemória méretétől. Ezekre vonatkozóan lehet alkalmazásspecifikus profilokat is létrehozni, hogy az adott meghajtó a program igényeit figyelembe véve menedzselje a videomemóriát. Itt meglehetősen sok sebességet lehet találni, tehát erre a rendszerprogramozók kiemelten figyelnek.
A grafikus meghajtó általi, vagyis lényegében közvetett memóriavezérlés azonban nem túl kedvező a fejlődésnek, mivel a fejlesztőket borzasztóan egyszerű programozási modellre kényszeríti. Ez a legfőbb oka annak, hogy például a hardveres megatextúrázáshoz előbb az API-ba kellett beépíteni a szükséges funkciókat (DirectX esetében ez a Tiled Resources), azután az eszközillesztőben erre készíteni kellett minden gyártónak egy implementációt, és így eljutunk arra a szintre, hogy a hardverek által támogatott funkciókat kihasználhassák a fejlesztők. Erre az egész, fájdalmasan lassú procedúrára csak azért van szükség, mert a videomemória nem érhető el közvetlen módon, vagyis a fejlesztő nem tud egymaga írni egy hardveres megatextúrázó implementációt az adott programba.
A cikk még nem ért véget, kérlek, lapozz!
