Miért különleges a Nitrous?
A teszt előtt érdemes beiktatni egy apróbb, mondhatni rendhagyó elemzést, ugyanis az Ashes of the Singularity című játék egy tényező miatt rendkívül különlegesnek tekinthető. Ez nem más, mint a Nitrous videojáték-motor, amelyről nagyon sokat lehetett hallani az elmúlt években, és természetesen a felé irányuló figyelem nem véletlen.
Az Oxide Games új stúdióként alakult meg 2013-ban, akiket nagyrészt a Stardock pénzel, illetve olyan iparági nagyágyúk alapították, mint Dan Baker, Tim Kipp, Marc Meyer, Brian Wade és Brad Wardell. Az úriemberek neve egyenként is elképesztően erős, aligha van náluk jobb szakember az iparágban az adott területeken belül, így igen nagy szó, hogy összefogtak egy közös cél érdekében, ami a stratégiai játékok reformja volt.
Nem túl ismert tény, hogy manapság jó minőségű, valós idejű stratégiai játékot a legnehezebb fejleszteni, nincs is túl nagy tolongás e téren. A gondokra jó példa a Starcraft 2, amely különböző technológiai problémák miatt egységlimittel rendelkezik, ami azt jelenti, hogy egy adott pályán egy bizonyos számú egységnél több nem építhető. Szerencsére ez a szám elég nagy, hogy csak ritkán okozzon problémát. Ennél sűrűbben bele lehet futni a 255 darabos kijelölési limitbe, amely szintén egy technikai gond, nem beszélve arról a jelenségről, amikor nagyszámú egység esik egymásnak, amitől teljesen lelassulhat az adott PC.
Gyógyír a gondokra
Az Oxide Games pont azért kezdett a nulláról, hogy a mára általánossá vált limiteket ki lehessen ütni egy jobban felépített alappal. A Nitrous videojáték-motor egyik különlegessége a SWARM rendszer, amely a Simultaneous Work And Rendering Model rövidítése. Ez egy olyan feladatalapú, alapjaiban a nagy és komplex szimulációkhoz tervezett alkalmazásmodell, amelyet évek tapasztalata alapján épített fel Dan Baker és Tim Kipp. A SWARM teszi lehetővé, hogy a Nitrous extrém mértékben skálázódjon a többmagos processzorokon. A határokat még nem lehet tudni, de a jelenlegi tesztek alapján a közel lineáris skálázódás 16 magig nem akadály, persze csak akkor, ha van mögötte elég gyors grafikus hardver.
Az extrém skálázódás azonban amellett, hogy jó, rengeteg problémát felvet. Például azt, hogy mennyi a valóban szabad, program számára ténylegesen hozzáférhető processzoridő. Utóbbit ugyanis nem csak a futó és egyben megterhelő alkalmazás, hanem az operációs rendszer és más komponensek is használják. A Nitrous esetében például rendkívüli limitációkat jelentettek anno a grafikus kernel meghajtók szerver szálai, ugyanis elvették a processzoridő egy jelentős részét, valamint sokszor soros munkavégzésre kényszerítették a rendszert, amitől hozzáférhetetlenné vált a hardverben létező erőforrások nagy része.
A DirectX 11 sok processzoridőt hagyott kihasználatlanul [+]
A fenti képen látható, hogy a DirectX 11 mellett gyakorlatilag csak a processzoridő egy kis részét használta a Nitrous kezdeti kódja, és a maradék rész egyszerűen hozzáférhetetlen. Dan Baker, a Nitrous vezető programozója korábban erről azt mondta, hogy a grafikus driverek működési modellje a rossz, mert kiszámíthatatlanul cselekednek, így képtelenség hatékony többszálú optimalizálást bevezetni. Ezért a Nitrous már a kezdetektől fogva az explicit API-kra készült. Az elején az AMD Mantle-re, míg ma már a DirectX 12 és a Vulkan API-ra is.
A végeredményben mindegy, hogy milyen explicit API-n fut a program, a skálázhatóságot a grafikus kernel meghajtó megszűnése biztosítja, így kikerül a képből az a kiszámíthatatlan tényező, amely megakadályozta a hatékony többszálú optimalizálást.
A cikk még nem ért véget, kérlek, lapozz!
