A PC-s játékpiac nem szemétlerakó!

Az idei évben a PC-s játékipar egyáltalán nem azt mutatta, amit várnak tőle a játékosok. Már az elmúlt években is viszonylag sok optimalizálatlan PC-s port érkezett, de az idei évben az egyes játékok optimalizálatlansága új mélységeket állított fel. Emlékezhetünk itt a csúfosan megbukott Batman: Arkham Knight PC-s verziójára, de a Call of Duty: Black Ops 3 és az Assassin's Creed Syndicate sem volt mintapélda. Utóbbi persze jobb lett, mint az előző évben csúfosan megbukott Assassin's Creed Unity, de még így is nagyon messze van attól, ami elvárható lenne.

A probléma röviden összefoglalva az, hogy nagyon megszaporodtak a rendkívül rossz optimalizálást használó PC-s portok, de a probléma gyökeréről senki sem beszél, illetve senki nem tesz semmit annak érdekében, hogy a PC-s játékiparon belül ne erősödjön ez az irány.

Az AMD most előállt egy átfogó megoldási javaslattal, amely kihúzhatja ebből a gödörből az egész PC-s játékipart. A legfontosabb szempont, hogy ami megtörtént, az megtörtént, nem lehet rajta változtatni, de kielemezve az egyes játékok fejlesztését, rá lehet jönni, hogy hol került homokszem a gépezetbe. Az AMD elmúlt évben végzett kutatásai szerint több alapvető problémával néz szembe az ipar. Egyrészt a PC-s és a konzolos fejlesztés túlságosan szegmentált, ami nem kedvez a multiplatform címek esetében a PC-nek. Másrészt sok grafikus vezérlő működése abszolút titok bizonyos fejlesztők előtt, ami megnehezíti az optimalizálást, harmadrészt pedig egyre több az úgynevezett feketedoboz, amely gyakorlatilag ellehetetleníti az optimalizálást.

A feketedoboz jelző talán nem ismert, de valójában azokat a rendszereket és middleware-eket nevezik így, amelyek esetében a forráskód nem látható a fejlesztők számára, vagy ha látható is, akkor sem módosítható. Ez okozza a legnagyobb gondot manapság a PC-s portok esetében, mert ha az adott middleware nem módosítható, és nem működik jól az adott leképezővel vagy annak bizonyos optimalizálásaival, akkor a leképezőt át kell írni, vagy ki kell szedni belőle az optimalizálást. Ilyen formában a zárt middleware által beépített elem hiába kapcsolható ki, a leképezőt a kompatibilitási problémákat okozó optimalizálások nélkül szállítják, véglegesen elvéve a sebességet a PC-s porttól. Ilyen formában a fejlesztők keze különböző licencszerződések által meg van kötve, és még ha érzik is, hogy az adott játék PC-s portja nem megfelelő, a különböző jogi kötelezettségek miatt nem tudják a gyökerénél kezelni a problémát.

A komplex problémára az AMD egy viszonylag egyszerű megoldást javasol a GPUOpen koncepcióval. A vállalat szerint az elmúlt években világossá vált számukra, hogy akkor működik a PC-s piac a legjobban, ha a fejlesztők megosztják egymással az innovációt. Bár erre senkit sem lehet kötelezni, de többször is bebizonyosodott már, hogy az "adj, hogy kaphass" elvű konstrukciók megfelelően felépített rendszer keretében abszolút működőképesek. A GPUOpen tulajdonképpen nem lesz más, mint egy fejlesztői epicentrum a GitHub portálon, ahol az iparág vezető szakemberei önszántukból oszthatják meg tapasztalataikat vagy akár fejlesztéseiket.

A koncepció a fenti problémákra direkt megoldást kínál. Egyrészt az ide felkerült kódok és csomagok akármin hasznosíthatók lehetnek. Konzol vagy PC? Mindegy, a hangsúly az optimalizáláson van. Másrészt a fejlesztők nemcsak kódokat oszthatnak meg egymással, hanem olyan információkat is, amelyekhez a fejlesztéseik során jutottak. Természetesen ez nem helyettesíti az egyes grafikus architektúrák jó dokumentálását, de ha egy fejlesztőnek egy problémára van megoldása és az bevált, akkor talán más leképező esetében is működhet. Ezzel azok a fejlesztők járnak kifejezetten jól, akiket a publikus dokumentációkkal nem rendelkező gyártók kvázi semmibe vesznek, így képtelenek hozzájutni olyan információkhoz, amelyek az optimalizáláshoz szükségesek lehetnek.

Végül pedig a middleware-ekre a nyílt forráskódú eljárások jelentik a megoldást. Ha az adott eljárás nem kompatibilis a leképezővel vagy a beépített optimalizációval, akkor fontos, hogy ne a leképezőt kelljen átírni vagy az optimalizálást kiműteni, hanem sokkal célszerűbb az effektet módosítani és kvázi kompatibilissé tenni. Ilyen formában a leképező megőrizheti az eredeti, optimalizált kódbázist az adott eljárás aktiválása mellett vagy nélküle, ami végső soron minden esetben jobb teljesítményhez, és ezzel együtt jobb játékélményhez vezet.

GPUOpen: fejlesztés nyílt formában

A GPUOpen kapcsán elsőként az AMD nyit. A konstrukció januárban kerül fel a GitHubra, és első körben számos, ma is elérhető fejlesztőkörnyezet és fejlesztőeszköz lesz hozzáférhető. Ezeket az alábbi kép fel is sorolja egy táblázatban.

Pár effekt is felkerül a GitHubra, amelyek elődjei korábban is elérhetők voltak a Radeon SDK keretében, de változik a licenckonstrukció, ami szabadabb felhasználást tesz lehetővé. Eddig úgy volt, hogy az effekt felhasználásakor az AMD-nek írni kellett egy elektronikus levelet, hogy melyik stúdió fogja felhasználni, melyik játékban. Ezt leszámítva persze szabad volt minden, így a forráskód módosítása is, de a módosítást már nem lehetett publikálni.

[+]

Az AMD ezt a licenckonstrukciót elvetette, és átállnak a MIT licencre. Ilyen formában a módosított kódok megoszthatóvá válnak, így az egész fejlesztés amolyan közösségi szájízt is kap. Bár arra korábban is volt példa, hogy az AMD a partnerek optimalizációit kiadta egy-egy effekt új verziójában, de a kiadást abszolút maguk intézték, és esetenként sokat csúszott. Az új licenckonstrukcióval a fejlesztések felgyorsíthatók, a GPUOpen ráadásul kötetlen, így az optimalizálásokat nem csak a fejlesztők, hanem a konkurens gyártók is biztosíthatják. Ez persze önkéntes jellegű, de a lehetőség adott.

Az effektek szempontjából a GPUOpen kezdetben négy eljárást kínál. A TressFX 3.0-t talán senkinek sem kell bemutatni, erre 2016-ban több játék is épít (bizonyos esetekben eltérő névvel, mint például PureHair). Persze a hajszimulálás nem az egyetlen opció, így lesz még GeometryFX, amiről sajnos még semmit sem tudni, illetve nyílt lesz az AOFX és a ShadowFX – utóbbi kettő, úgy tudjuk, a HDAO+ és a CHS+ effekteket jelölik, mindkettő megtalálható a DiRT Rally című játékban. Később új effektek kerülnek majd bele a csomagba, és itt jön a lényeg: ezeket nem csak az AMD szállíthatja. A vállalat csak elkezdte, és persze folytatni is fogják, de a GPUOpen igazi célja a közösség által fejlesztett eljárások megosztása, optimalizálása és alkalmazása a játékokban.

A GPUOpen független lesz az API-któl, így bár a startkor a DirectX 11 kap főszerepet, gyorsan jönnek majd a DirectX 12 és Vulkan API-hoz írt eljárások is. Itt viszont van egy megkötés: a GPUOpen egy iparági szabványokat követő kezdeményezés, tehát olyan kódok nem kerülhetnek fel, amelyek specifikus, nem szabványos API-kra épülnek.

A GPUOpen konstrukciót természetesen csak januárban, a GitHub portál megnyitásakor lehet ténylegesen megítélni, de leírása alapján évek óta ez az első kezdeményezés arra, hogy a PC-s játékpiacot újra értékelhető szintre emeljék, illetve lehetőség szerint megszabadítsák a felhasználókat az optimalizálatlan PC-s portoktól, amelyek az elmúlt egy-két évben nagyon durván elszaporodtak.

Abu85