Ezt kínálja a Mantle
Az AMD számára persze ez még csak egy lehetőség, mivel le kell rakni az asztalra azt a rendszert, amit a fejlesztők szeretnének. Az alacsony szintű hozzáférés a hardverhez jól hangzik, de a kivitelezése nem olyan egyszerű. Számos olyan döntést kell meghozni, ami befolyásolja az API működését és hatékonyságát. Éppen ezért a cég nem vállalta fel egymaga a fejlesztést, így Johan Andersson, a DICE motorprogramozója lett a legfőbb tanácsadó. Később több fejlesztő is részt vett a projektben, többek között Dan Baker is. Az ő tapasztalatai sokat számíthattak, hiszen a DirectX 9 és 10 fejlesztésében is szerepet vállalt, és az egyetlen ember a világon, akinek sikerült hatékony implementációt írnia a DirectX 11 többszálú feldolgozását biztosító deferred context funkciójára. Az AMD tehát nem bízta a véletlenre, így nem saját nézőpontból, hanem sokkal inkább a vezető fejlesztők visszajelzései alapján tervezték meg a Mantle-t.
Az elsődleges szempont a többletterhelés minimalizálása, hogy a fejlesztők PC-n is minimum annyi rajzolási parancsot dolgozhassanak fel hatékonyan, amennyit a konzolon. A PC-n ez sajnos évek óta problémát jelent, mivel még maguk a gyártók sem értenek egyet abban, hogy képkockánként mennyi rajzolási parancs ideális. Amit évek óta mindenki hangsúlyoz, hogy ezeket kötegelni kell, így egyszerre több objektum is kirajzolható egyetlen paranccsal, amivel drámaian gyorsítható a feldolgozás, de a kötegelés a gyakorlatban nem olyan egyszerű.
Nem lehet csak úgy mindent vadul kötegelni, így szép számmal lesznek olyan objektumok, amelyek úgymond egyediek, így muszáj egy rajzolási parancs kiadása. Az Intel szerint az az ideális, ha a fejlesztő kétezer rajzolási parancs alatt marad képkockánként, míg az AMD és az NVIDIA – annak ellenére, hogy jóval modernebb driverekkel rendelkeznek – tízezer rajzolási parancsnál többet nem ajánl. Eközben már az előző generációs konzolokon is el lehetett érni a képkockánkénti húszezer rajzolási parancsot, és az új generációs gépek még ennél is továbblépnek.
[+]
Az AMD elmondása szerint a mai, nagyon modern játékok képkockánként három-ötezer paranccsal dolgoznak, de a profi fejlesztők különböző trükkökkel képesek elérni a tízezres szintet anélkül, hogy nagyon kivégeznék a teljesítményt. A Mantle azonban teljesen új strukturális működést használ, így képkockánkénti százezer rajzolási parancs volt a célkitűzés, amit megfelelő hardverek mellett képes is teljesíteni az API. Ez az AMD szerint kellően jó alap az új generációs konzolok mellett, így Mantle leképzővel biztos nem kell butítani a PC-s portok grafikáján.
[+]
Az extrém mértékű előrelépés az új végrehajtási modellnek köszönhető, ami a grafikus vezérlőt három logikai részre osztja: grafika, compute és DMA. Ezekhez több parancslista tartozik, melyek lényegében a végrehajtásra váró parancsokat tárolják, és sorban ráengedik a hardverre azokat. Az igazán lényeges újítás azonban, hogy az alkalmazás oldalán a parancsok feldolgozása valóban több szálon fut egymástól teljesen függetlenül.
[+]
A DirectX és OpenGL API-kra épülő alkalmazások esetében a feldolgozás még mindig egyetlen processzorszálra van korlátozva, amin a DirectX 11-ben bevezetett deferred context funkció sem segít sokat, mert rendkívül sok szinkronizáció szükséges ahhoz, hogy a program egyáltalán fusson. Ráadásul az NVIDIA implementációjában a szinkronizációhoz a grafikus driver egy processzormagot teljesen lefoglal a parancslista kezelésére, ami két maggal rendelkező processzorok esetében nem kedvező. Az AMD és az Intel pont ezért kerüli a parancslista implementálását, mert nem minden szempontból előnyös, ráadásul a fejlesztők is inkább manuális többszálúsítást próbálnak megvalósítani, ami persze sokkal több időbe kerül, de legalább hatékonyabban fut, mint egy deferred context implementáció, mivel a mai driverek tartalmaznak különféle hackeket a többmagos processzorok erejének hasznosítására. A helyzet azonban az, hogy az így nyert sebesség az egyszálú feldolgozáshoz képest nem túl nagy, viszont ettől függetlenül rengeteg optimalizálást igényel. Ezt a nagyobb stúdiók megteszik, de aránytalanul sok a befektetett munka pár százalékos gyorsulásért. A Mantle eltérő működése azonban technikailag lineáris skálázást tesz lehetővé, ráadásul tényleg rengeteg szál futhat párhuzamosan. Ez a jövő szempontjából még kedvezőbb, mivel ha a mai nyolcmagos processzorok után esetleg lesznek 10-12-16 magos opciók, akkor abból a DirectX leképző tulajdonképpen nem profitál, miközben a Mantle kód folyamatosan gyorsul.
A rajzolási parancsok feldolgozására használt szálak mennyiségét egyébként az adott program fejlesztője határozhatja meg egyéni szempontok szerint. A legnagyobb különbség tehát az aktuális API-khoz képest, hogy a Mantle közvetlenül a fejlesztők kezébe adja a kontrollt.
Az AMD API-jának memóriamodellje is egészen újnak tekinthető. A fejlesztő konkrétan látja a grafikus vezérlőhöz rendelt memóriát. Nincs elrejtve a WDDM mögé, nem az operációs rendszer kezeli, nincsenek többet előre definiált pufferek, így direkten lehet benne dolgozni. Ez azt is jelenti, hogy az API objektumok nem foglalnak maguknak külön memóriaszeletet, hanem egyszerűen csak egy linket tartalmaznak a megfelelő memóriarészhez. Ráadásul a Mantle mellett kihasználható a memória virtuálizálása, illetve tulajdonképpen a direkt kontroll hatására a fejlesztők lényegesen kevesebb memória felhasználásával képesek ugyanazt a feladatot megoldani, emellett számottevően gyorsabb tartalomstreamelést biztosító algoritmusok írhatók.
[+]
Az erőforrás-menedzsment is teljesen újszerű, nincsenek különböző pufferek, textúrák, textúratömbök, illetve UAV-k, így a memóriában alapvetően lehet memóriazóna és leképzőzóna. Ezt a két erőforrást különböztetik meg, ami gyakorlatilag drámaian leegyszerűsíti az egész rendszer működését.
[+]
Ezek mellé új binding modell is jár, amire azt is lehetne mondani, hogy bindless modell, ugyanis a shader csak kiválasztja az erőforrást, amit használni akar, és kész – a processzor beavatkozására abszolút nincs szükség.
A cikk még nem ért véget, kérlek, lapozz!
