Hirdetés

PC és konzol, avagy az új generációs játszma

Mi a konzol előnye?

A konzol és a PC harca évek óta tart. A játékosok az elmúlt évek során zömében átálltak konzolra, de a PC-s tábor is igen nagy, ami állandó harcot jelent a két nézőpont között. Vitathatatlan tény, hogy mindkét oldalnak megvannak a maga előnyei, és ezek annyira egyértelműek, hogy nem is érdemes érvelni ellenük vagy mellettük. A technikai oldalon azonban állandó kérdés, hogy a konzol vagy a PC a jobb. Így van ez az új generációs masinákkal is, ugyanis az iparág résztvevői igen ellentétes véleményt formáltak a termékekről.

A fejlesztőknek egységesen tetszenek az új konzolok, miközben az NVIDIA szóvivője hivatalosan is úgy látja, hogy ezek csak belépőszintű PC-k. Nyilván egyik álláspont sem tekinthető független véleménynek, hiszen a fejlesztőknek a konzol jelenti a megélhetést, míg az NVIDIA fenyegetésként tekint az új masinákra, így az eddigi nyilatkozatok mondhatni megfelelnek az adott cég érdekének. Ideje tehát egy olyan elemzésnek is, ami a különböző gépek paramétereit és képességeit veti össze, így kiderülhet, hogy az új generációs játszma merre tereli majd a játékpiacot.

A konzolok esetében a fejlesztők régóta azt az általános előnyt fogalmazzák meg, hogy a gépeket specifikusan játékokhoz tervezik. Ez elsősorban nem a hardver felépítésében, hanem sokkal inkább az operációs rendszer, az API-k és a fejlesztőkörnyezetek kialakításában nyilvánul meg.

A Sony és a Microsoft jó ideje úgy építi fel a konzolokat, hogy a fejlesztők egyfajta libGCM (az első modern elvek szerint tervezett grafikus API) stílusú, alacsony szintű hozzáférést kapjanak a hardverhez, vagy esetleg megtehetik, hogy a rendszert a saját assembly nyelvi szintjén programozzák, mivel a hardver a termék életciklusa alatt nem változik meg. Utóbbi persze annyira nem jellemző, hiszen nem egyszerű kivitelezni, de egy libGCM stílusú API abszolút indokolt. Persze a könnyebb programozhatóság érdekében a konzolok is használhatnak magas szintű hozzáférést, ami sokkal lassabb ugyan, de a manapság divatos, hétköznapi felhasználókat megcélzó játékokhoz bőven elég.

Hirdetés

A legtöbb, konzolra írt játék esetében viszont elmondható, hogy libGCM stílusú API-t használnak a fejlesztők, és ez az új generációs Xbox One és a PlayStation 4 esetében is így lesz. Ennek a működési módnak alapvető előnye a PC-vel szemben, hogy mellőzi a grafikus drivert, így a hardver elérése nagyságrendekkel gyorsabb. Ezt akár szemléltetni is lehet, és az alábbi két ábrával meg is tesszük:

A grafikus hardver jellemző elérése PC-n
A grafikus hardver jellemző elérése PC-n [+]

A grafikus hardver jellemző elérése konzolon
A grafikus hardver jellemző elérése konzolon [+]

Látható, hogy a grafikus hardver és a program között a konzolon lényegében igen csekély a többletterhelés (overhead). Ez azt jelenti, hogy a program által kiadott parancs optimálisan lesz végrehajtva, miközben a PC-n egy igen bonyolult procedúrára van szükség ahhoz, hogy az adott grafikus API-n keresztül elért hardver megtegye azt, amit a program kér. Ez igen komoly sebességvesztésben nyilvánul meg, és erre a fejlesztők jellemzően a rajzolási parancsokat szokták felhozni példaként, amelyek PC-n jobb esetben tízszeres, rosszabb esetben akár százszoros többletterheléssel oldhatók meg a konzolokhoz viszonyítva.

Alacsony szintű hozzáférést PC-re is!

Az előző oldalon leírtak kapcsán felmerülhet a kérdés, hogy PC-n miért nincs ilyen libGCM stílusú API, ami alacsony szintű hozzáférést biztosítana a hardverhez. Nos, erre röviden annyit lehet válaszolni, hogy mindegyik cég grafikus processzora más utasításarchitektúrát használ, így pedig az alacsony szintű kompatibilitás biztosítása igen nehéz feladat. Maga a téma viszont érdekes annyira, hogy jobban belemélyedjünk a dolgokba. Megjegyzendő ugyanis, hogy a történelem során számtalanszor felmerült már az igény egy univerzális utasításarchitektúrára a grafikus vezérlők esetében is, vagyis a PC-s API-k többletterhelését mindenki nagyon komoly problémának tekinti. Valójában az is, de eddig minden koncepció, ami ezek kiváltására tört, a süllyesztőben végezte.

Az egyik grandiózus projekt a PC-s API-k megkerülésére a Larrabee volt, amivel az Intel egy olyan grafikus processzort szeretett volna kidolgozni, mely ugyanazt az utasításarchitektúrát használja, amit a PC-s központi processzorok. Ezzel a cég azt is jelezte, hogy egyetértenek az univerzális utasításarchitektúrára vonatkozó koncepcióval, és a lehető leghamarabb a tettek mezejére léptek. A cél lényegében az volt, hogy az x86 ne csak a központi processzorok, hanem a grafikus processzorok piacán is kiemelt hatalmat kapjon. Ennek érdekében a vállalat éveken keresztül pumpálta a projektbe a dollármilliárdokat, fittyet hányva azokra az iparági figyelmeztetésekre, melyek megpróbálták elmagyarázni a cégnek, hogy elméletben kiváló koncepciójuk a gyakorlatban nem fog működni.

A Larrabee végül a süllyesztőben végezte, de a projekt MIC néven él tovább. Viszont a számtalan áttervezés és vezércsere mellett még ma sem látjuk, hogy a gyakorlatban mennyire gyorsan képes futtatni egy aktuális játékot, és az Intel a nagyszabású, univerzális utasításarchitektúrát bevezető terveiről egyelőre lemondott. A Larrabee problémája egyébként az iparági szakértők véleménye szerint az volt, hogy az x86-ot alapvetően nem úgy tervezték, hogy megfelelően skálázódjon egy adatpárhuzamos végrehajtásra tervezett hardverben. Ez logikus is, hiszen amikor az utasításarchitektúra alapjait letették, akkor még fel sem merült, hogy valaha is lesznek többmagos processzorok. Márpedig a grafikus vezérlők esetében az adatpárhuzamosságot konkrétan beletervezik az adott utasításarchitektúrába, és a GPU-kon pont ezért skálázódik a teljesítmény igen jó hatásfokkal.

Az Intel elképzelése egyébként úgy még működőképes lehet, hogy ha a feldolgozáshoz szükséges adatok mindig ott vannak a processzormag mellé társított gyorsítótárban. Ilyenkor a skálázódás megfelelő szintet érhet el, viszont így a lapka igen nagy része csak gyorsítótárból állna, miközben a futtatott munkafolyamatok alapvetően tolerálják a késleltetést, vagyis az egész koncepció átcsap egy masszív tranzisztorpazarlásba. Ezt úgy érdemes felfogni, hogy amíg az Intel a tranzisztorok milliárdjait csak azért építi be, hogy a nagyobb gyorsítótárakkal segítsék a skálázódást, addig a más elvű rendszerrel dolgozó konkurenciának ezzel nem kell foglalkoznia, így az extra tranzisztorokat extra teljesítményre költhetik. Ezek után könnyen belátható, hogy a Larrabee eredeti elképzeléséből miért nem lett semmi.

A központi, azaz lényegében a késleltetésre optimalizált processzormagokhoz tervezett utasításarchitektúrák tehát kiestek a képletből, de még mindig ott volt a lehetőség, hogy a grafikus processzorok fejlesztésével foglalkozó cégek megegyezzenek egy adatpárhuzamos végrehajtásra tervezett univerzális utasításarchitektúráról. Ez a koncepció elvi síkon ezt jelentené, hogy a fejlesztő az adott programot konkrétan lefordítja a mindenki által használt utasításarchitektúrára, és a hardver azt képes lenne direkten futtatni. Ez az elv működik a központi processzoroknál, hiszen az x86/AMD64-re lefordított programok futnak az AMD, az Intel és a VIA megfelelő processzorain, és ugyanez igaz a jóval népesebb ARM-os rétegre is az ARM-ra fordított alkalmazások mellett. A többletterhelést ezzel teljesen ki lehetne ütni, hiszen eltűnne az API-ra az igény, de gondot jelent, hogy a gyakorlatban ez az elképzelés sem megvalósítható.

Bár az előbbi bekezdés mindenképp jól hangzik elvi síkon, de ahogy korábban már említettük, a grafikus processzorok alapvető tervezési koncepciója, hogy skálázható legyen a rendszer. Nagyon érdekes megnézni az iparágat ebből a szempontból, hiszen majdnem egy tucat cég foglalkozik ma GPU-k tervezésével, viszont közülük csak az AMD és az NVIDIA tesz le nagymértékben skálázható architektúrákat az asztalra. Bár ez az adat jelentéktelennek tűnhet, de valójában nagyon is fontos tényezőről van szó, ugyanis egy grafikus számításokra tervezett rendszer teljesítményének skálázhatóságát nagymértékben befolyásolja az adott utasításarchitektúra. Olyannyira, hogy még az AMD és az NVIDIA is le szokta cserélni ezt nagyjából 4-6 éves ciklusokban, és ugyanezt megteszi a többi cég is, csak valamivel tágabb időintervallumok mellett.

Az univerzális utasításarchitektúra ötlete tehát teljesen megbukott, mivel a teljesítmény skálázódása mindenki számára sokkal fontosabb a kompatibilitásnál, így pedig a hardverekhez való alacsony szintű hozzáférés megvalósítása is nehéz ügy, hiszen nincs egy közös pont, amit reálisan meg lehetne ragadni.

Van még fény az alagút végén

A HSAIL, mint lehetséges irány
A HSAIL, mint lehetséges irány

A fentebb leírt adatok lehangoló jövőképet festenek, de a PC-s grafikus API-k által okozott többletterhelés annyira komoly probléma, hogy a cégek még ma sem adták fel a küzdelmet egy jobb jövő érdekében. Bár a fizikai szinten implementált utasításarchitektúra nem lehet közös, de létezik egy mentőöv, ami kihasználható. Mivel maguk a gyártók is viszonylag sűrűn cserélik az utasításarchitektúrát, mindenképp biztosítani kell egy olyan kompatibilitási rést, amivel az új hardverek is képesek futtatni a régieken kitesztelt programokat. A grafikus API-k mellett ugyanis ma már az általános számításra kihegyezett platformok is jelentős piacot szereztek, így meg kell oldani, hogy egy OpenCL-ben írt program bármilyen OpenCL-t támogató hardveren fusson. Erre az érintett cégek az úgynevezett virtuális utasításarchitektúrákat alkalmazzák. Ezeknek hála a fizikai szinten implementált utasításarchitektúra megváltozhat, miközben a kompatibilitás virtuális szinten biztosított.

Az AMD, az ARM, a Qualcomm, az Imagination Technologies, a Vivante és a DMP összefogott annak érdekében, hogy ha már a közös utasításarchitektúra használata elvi szinten nem lehetséges, akkor legalább a virtuális utasításarchitektúra szempontjából legyen egyezés. Ez már egy reálisan vállalható elképzelés, hiszen a skálázhatóság érdekében mindenki úgy tervezheti az adott rendszert, ahogy akarja, és eközben kellően alacsony szinten lesz egy olyan közös pont, amire a fejlesztők építhetnek. Ez a közös pont jelenleg a HSAIL, melyhez tervezhető egy olyan grafikus API, amivel konzolokhoz hasonló feldolgozási elv érhető el, ezzel búcsút intve a komoly problémának tekinthető többletterhelésnek. Gondot jelenthet viszont, hogy ezt az elképzelést az Intel, illetve az NVIDIA nem támogatja, és amíg ebből a szempontból nincs teljes megegyezés, addig a PC görgeti maga előtt az aktuális grafikus API-k extrém mértékű többletterhelését, ami komoly előnyt ad az új generációs konzoloknak.

A képességek bűvkörében

Valószínűleg nem írunk újat azzal, amikor kijelentjük, hogy a konzol hardvere az életciklusa alatt sosem módosul, így pedig az elérhető képességeket is ehhez a fix hardverhez igazíthatja az adott masina gyártója. Ez az Xbox One és a PlayStation 4 esetében sincs másképp, így nem csak a hardver elérése hatékonyabb, hanem a fejlesztők által kihasználható tudás is igencsak más ligát képvisel a PC-s szinthez képest.

Rengetegszer olvasni, hogy mindkét új konzol csak egy PC, hiszen az egyedileg tervezett AMD APU-kban Jaguar magokból álló processzorrész és GCN architektúrára épülő IGP dolgozik, amelyekre a vállalat PC-s termékekben is épít. Logikus tehát azt gondolni, hogy a konzolok semmivel sem tudnak többet, mint egy GCN architektúrára alapozó Radeonnal felvértezett PC. Ez azonban igen nagy tévedés. Nagy különbség van ugyanis aközött, hogy elméletben mit tud a hardver, és hogy abból mit használ ki a legmodernebb PC-s grafikus API, jelen esetben a nemrég megvizsgált DirectX 11.1. Mielőtt ennek okait felvázolnánk, az alábbi táblázatban részletezzük, nagyjából milyen fontosabb eltérésekről van szó:

Platform Xbox One PlayStation 4 PC (DirectX 11.1)
Shader kódba beköthető egyedi textúrák száma nincs korlátozva 128
Támogatott UAV-k száma nincs korlátozva 64
Egyidejűleg írható és olvasható UAV formátumok bármelyik single uint32
Hardveres virtuális textúrázás van nincs

A grafikus API-val dolgozó PC esetében a korlátozások nagyon extrémek, főleg ahhoz képest, amit az új generációs konzolok nyújtanak. Persze senki se számítson arra, hogy minden fejlesztő végtelen mennyiségű UAV-t használna, vagy esetleg korlátlanul kötné be a kifogyhatatlan egyedi textúrákat a shader kódokba, hiszen könnyen kitalálható, hogy ilyen elv mellett soha sem futna le az adott kód. Az viszont biztos, hogy a DirectX 11.1 megszorításait már túl lehet lépni, és erre igény is lenne.

Nyilván nem kérdés, hogy az igényeket mindenki látja, még a Microsoft is, így nem azért tervezték ilyenre a DirectX 11.1-et, mert az Xbox One-nak szeretnének durva előnyt adni, hanem elsősorban azért léteznek ezek a korlátok, mert a PC-n nem egy, hanem igen sok GPU-t kell támogatni. A legmodernebb rendszerek esetében nem teheti meg az API, hogy csak a legjobb hardvert veszi figyelembe, így a cégek együttesen hozzák meg azokat a döntéseket, hogy az új DirectX verziókban mi lesz a követelmény.

Architektúra AMD GCN NVIDIA Kepler Intel Gen7.5
Shader kódba beköthető egyedi textúrák száma nincs korlátozva 1 048 576 128
Támogatott UAV-k száma nincs korlátozva 8 64
Egyidejűleg írható és olvasható UAV formátumok bármelyik single uint32 single uint32
Hardveres virtuális textúrázás van nincs nincs

A fenti táblázatban összegeztük az AMD, az NVIDIA és az Intel aktuális legjobb architektúráinak elvi képességeit, amivel látható, hogy miért tud a DirectX 11.1 annyit, amennyit. Gyakorlatilag az NVIDIA még ezt sem képes teljesen támogatni, hiszen a Kepler nem kezel megfelelő mennyiségű UAV-t, eközben a shader kódokba beköthető egyedi textúrák számát az Intel Gen7.5 korlátozza le 128-ra.

Természetesen a DirectX és lényegében bármelyik más grafikus API képességei javíthatók, így a korlátokat, ha nem is lehet eltörölni, mindenképp ki lehet terjeszteni. A fejlesztők már ezer beköthető egyedi textúrával is elégedettek lennének, továbbá úgy 100 UAV bőven megfelelne a teljes futószalagra nézve, illetve ha már az igényeknél tartunk, akkor nem ártana a hardveres virtuális textúrázás egységes támogatásának megoldása sem.

Kétségtelen, hogy a legnagyobb problémát az UAV-k számára vonatkozó korlátozás jelenti, ugyanis a fejlesztők a lehető legtöbb effektet szeretnék compute shaderrel megoldani. Ez nagymértékben gyorsítaná a számításokat, miközben a minőségre nem lenne hatással. Utóbbi akár javítható is, hiszen a nagyobb sebesség több számításra ad lehetőséget.

A 64 darab UAV ebből a szempontból annyira nem rossz kezdés a DirectX 11.1-től, de ha 15-20 effektet átír a fejlesztő compute shaderre, akkor ebből is ki lehet futni. Példaként gondolhatunk itt arra, hogy a mélységélesség (depth of field) a mai játékok egyik slágereffektje, és jó minőségben ezt igen sok számítás mellett lehet abszolválni, ráadásul több menetben, ami jelentős extra terhelés. Megoldás persze van, hiszen létezik egy menetben dolgozó, compute shaderes algoritmus, de ez meg egymaga hat UAV-t igényel. Itt igen rémisztő látni, hogy az aktuálisan legjobb mélységélesség-implementáció használatával a DirectX 11-ben gyakorlatilag két UAV marad a többi effektre.

Az Xbox One és a PlayStation 4 a korlátok elkerülésével rengeteget profitálhat, hiszen a fejlesztő nem azt fogja számolgatni, hogy a programja hogyan férhet bele az API korlátozásaiba, hanem konkrétan csak arra kell figyelnie, hogy az adott algoritmus a lehető leggyorsabban fusson le. Persze a PC esetében már jönnek a gondok, így az adott effekteket le kell cserélni, vagy rosszabb esetben el kell távolítani a PC-s portból. Utóbbit senki sem szeretné, így könnyen lehet, hogy a legfőbb megszorítások megszüntetésére igen gyorsan jön majd egy újabb DirectX frissítés.

Az új konzolok felépítése

Az API persze nem az egyetlen előnye az új generációs konzoloknak, de ez az a terület, ahol kicsi az esélye, hogy a PC teljesen behozza lemaradását. A másik nagy újítás, hogy mind az Xbox One, mind pedig a PlayStation 4 egyetlen szilíciumszeleten egyesíti a CPU-t és a GPU-t. Ez manapság már nem számít újdonságnak a PC-be szánt lapkák esetén, de az új konzoloknál az integráció foka igen extrém, ami lényegében a fejlesztők kérése volt, hogy végre új szintre emelhessék a játékélményt.

A konzolok képességei jórészt ismertek. Egyedül az órajelek nincsenek tisztázva, de bármi is legyen, az Xbox One lesz ennek a generációnak a gyengébbik megoldása, így aki csak a nyers erő szempontjából dönt, annak a PlayStation 4 ajánlható. Persze fontosnak tartjuk megjegyezni, hogy egy konzolnál ez nem feltétlenül nyerő stratégia, hiszen hiába a némileg erősebb hardver, ha valamelyik kiszemelt játék nem lesz elérhető PlayStation 4-en. Elsősorban tehát továbbra is úgy tartjuk, hogy a konzolt az exkluzív tartalom alapján érdemes kiválasztani, de mivel jelen írásunk a technikai részletekkel foglalkozik, így az alábbi táblázatban összefoglaljuk, hogy mi a különbség a két új masina között:

Platform Xbox One PlayStation 4
Felhasznált lapka speciális AMD APU speciális AMD APU
Processzorarchitektúra

AMD Jaguar

Processzormagok száma 8 8
L2 gyorsítótár mérete 2 x 2 MB 2 x 2 MB
Integrált grafikus vezérlő AMD GCN architektúra
CU-k száma 12 18
Shader részelemek száma 768 1152
Textúrázó csatornák száma 48 72
Beágyazott memória 32 MB ESRAM -
ESRAM sávszélessége 102 GB/s -
Rendszermemória kapacitása 8 GB 8 GB
Rendszermemória típusa DDR3 GDDR5
Memóriabusz 256 bit 256 bit
Rendszermemória effektív órajele 2133 MHz 5500 MHz
Rendszermemória sávszélessége 68,3 GB/s 176 GB/s

Az adatok igazából magukért beszélnek. Információink szerint a processzormagok órajele 1,6 GHz lesz mindkét gép esetében, és az IGP-k órajele is egyezni fog – egészen pontosan 800 MHz lesz. Persze ezek az értékek tényleg változhatnak még a megjelenésig, de nincs az az extra órajel, amivel az Xbox One-ba szánt APU gyorsabb tudna lenni a PlayStation 4-be fejlesztett megoldásnál. Az Xbox One lapkájának lényegi előnye a 32 MB-os ESRAM, ami viszont az adatátviteli tempó tekintetében nem olyan gyors, mint a PlayStation 4-hez társított rendszermemória, ugyanakkor nagyságrendekkel kisebb késleltetés mellett érhető el. Ez bizonyos feladatok elvégzésénél tényleges előnyt jelenthet, de kevés ahhoz, hogy a PlayStation 4-en fogást találjon.

Microsoft Xbox One
Microsoft Xbox One [+]

Mivel mindkét gépben ugyanaz, az AMD által fejlesztett architektúra dolgozik, így ennek vizsgálatát érdemes összevontan kezelni, hiszen a teljesítménykülönbségeket leszámítva az APU-k elvi működése közel azonos.

Sony PlayStation 4
Sony PlayStation 4 [+]

Sokakban megfogalmazódhat az a kérdés, hogy az új konzolok miért APU-t használnak, és miért nem maradtak a jól bevált, dedikált GPU-knál. Ezért ismét a fejlesztők felelősek, ugyanis a Microsoft és a Sony elhatározta, hogy az új generációs gépeket a játékprogramozók véleményét figyelembe véve fejlesztik, mert a PlayStation 3 és az Xbox 360 is kapott komoly kritikákat a fejlesztőktől. Főleg az előbbi rendszert, pontosabban annak Cell processzorát nem szerették, de az Xbox 360 esetében sem volt mindenki kibékülve a Xenos grafikus vezérlőhöz társított 10 MB-os EDRAM-mal. Természetesen minden véleményt el lehetett fogadni, de a Microsoft és a Sony az új gépek esetében konkrétan megkérdezte, hogy a tartalmat készítő partnerek mit szeretnének.

Az utóbbi időben kiderült, hogy a legfontosabb igény az, hogy a központi és a grafikus processzor egységes címteret használjon, illetve teljesen koherens memóriát osszanak meg egymással. Az érdeklődő cégek között a Microsoft és a Sony a véleményeknek megfelelően írta ki a pályázatot. Úgy tudjuk, hogy túl nagy versenyhelyzet nem alakult ki, mivel csak az AMD vállalta el a projektek elkészítését az idei esztendő végére. A lényegi verseny hiánya elsősorban a konzolgyártók hibája volt, hiszen mindkét cég nagyon szűk fejlesztési határidőt húzott meg. Ez gyakorlatilag azt jelentette, hogy amelyik cég nem tervezett mély integrációt 2013-ra, helyből kiesett a játékból.

A rendszerszintű integráció előnyei

Az AMD – eleget téve az igényeknek – olyan APU-kat tervezett, amelyekben az IGP gyakorlatilag nem csak egy különálló vezérlő speciális, jórészt grafikai számításokra, hanem konkrétan a rendszerek szerves része. A GCN architektúra híres arról, hogy a komplex feladatokat igen extrém hatékonysággal oldja meg, és ezt a képességét az új konzolokban alaposan kamatoztathatja.

Az integrált grafikus vezérlő mindkét gépben nyolc darab Asynchronous Compute Engine (ACE) egységgel dolgozik, és ez a felépítés alapvetően azért alakult így, hogy a nyolc darab processzormagot a fejlesztők ne is nagyon használják másra, mint a különböző feladatok kezelésére, amit végső soron az IGP multiprocesszorai dolgoznak majd fel. Ilyen elv mellett a nyolc Jaguar processzormag és a nyolc ACE egység jelent nyolc darab futószalagot, melyek egyenként nyolc darab bekötött szimultán munkafolyamatot kezelnek. Ezzel a modellel az általános és a grafikai feladatok közötti kontextusváltás rendkívül gyors lehet, illetve a feladatokhoz kapcsolódó utasításfolyamok jól priorizálhatók az ACE egységek soron kívüli feldolgozást engedő out of order logikájával.

Az ACE egységek érdekessége még, hogy támogatják az eszköz statikus particionálását. Ezzel a működési móddal előre meg kell határozni az IGP erőforrásainak felosztását az általános és a grafikus feladatok között. Ezt nagyon egyszerű megtenni mindkét konzolon, hiszen fix hardverekről van szó, vagyis az alkalmazást direkten lehet optimalizálni. A grafikus vezérlőkbe épített DMA motorok is komoly előnyt jelentenek, mivel a PC-s API-kban minden memóriamásolás implicit, azaz közvetett, így a fejlesztőnek nincs túl nagy kontrollja felette. A konzolokon viszont lehetőség lesz aszinkron memóriamásolásra a grafikus futószalag működésének leállítása nélkül, nagyon alacsony késleltetésű ütemezés mellett, ami a tartalom streamelésének nagyon jót fog tenni.

A konzolok legnagyobb előnye, vagyis az egységes memória
A konzolok legnagyobb előnye, vagyis az egységes memória [+]

Mindkét gépbe szánt APU úgymond mély integrációt használ. A PlayStation 4 egy módosított, de alapjaiban hUMA architektúrával dolgozik, míg az Xbox One – az eddigi adatok alapján – egy eltérő, de nagyon hasonló rendszerrel, amiről sajnos még nem publikus minden adat. A lényeg azonban, hogy az integrált grafikus vezérlő megossza a memóriát a processzormagokkal. A Microsoft rendszerét nem tudjuk vizsgálni, illetve a módosítások ismerete nélkül a PlayStation 4-ről sincsenek egészen pontos információk, de a hUMA fő funkciói között a bidirekcionális koherencia szerepel, vagyis minden egyes feldolgozott elemen történt változást látják a processzormagok és a grafikus vezérlő multiprocesszorai is. Az integrált grafikus vezérlő ráadásul képes lesz kezelni a laphibákat, elérheti a teljes rendszermemóriát és a virtuális memóriát, továbbá ugyanazokat a pointereket kezeli, amelyeket a processzormagok, így elkerülhetők az adatmásolások is. Ez ma igen nagy problémát okoz, tehát nem véletlen, hogy a fejlesztők meg szeretnének szabadulni a különálló memóriaterületektől.

Tisztán látszik, hogy az integrált grafikus vezérlő már csak részben számol majd grafikát. A rendszert alapvetően arra tervezték, hogy számos jól párhuzamosítható általános feladaton dolgozzon, amelyek ma még a központi processzormagokon futnak. Többet között áthelyezhető a frustum és occlusion culling (kivágási feladatok), a rendezés, a különböző fizikai hatások számítása, a tartalomkikódolás, illetve a mesterséges intelligencia útkeresése.

Rendszerszintű integráció a gyakorlatban

A konzolokba tervezett APU-kban az összes hardveres újítás arra vonatkozik, hogy a fejlesztők a GPGPU (grafikus processzoron végzett általános számítási feladatok) algoritmusokat ne csak a grafika minőségének javítására, hanem a játékmenet befolyásolására is kiterjesszék. Erre bonyolult és egyszerű példákat is fel lehet hozni. Utóbbira vonatkozóan megemlíthető, hogy részecskeeffekt szinte minden modern játékban van. Gondolhatunk itt a füstre, ami egy alapvető játékelem. Ez azonban csak vizuálisan jelenik meg, vagyis a füstöt lényegében csak a felhasználó látja. Ennek az oka, hogy az aktuális játékokban soha semmilyen GPGPU-s részecskeszimuláció nem kerül visszaírásra a játék jelenetének számításába. Ennek az egyik hatása, hogy a füstre nem reagálnak direkten a virtuális világban kóborló szereplők, így rengeteg trükköt kell bevetni, hogy a mesterséges intelligencia egyáltalán felfogja, hogy a játékos olyan helyen van, amit az adott gép által irányított ellenfél nem láthat, így ne is tüzeljen oda.

Aki viszonylag sok játékkal játszott, tapasztalhatta már, hogy a mesterséges intelligencia nincs mindig a helyzet magaslatán, így például előfordulhat, hogy a felhasználó érzi, hogy a füst szélén áll, így az ellenfelek elméletben biztos látják, de mégsem tüzelnek. Valójában a gép által irányított karakterek csak azt csinálják, amit a program kér tőlük, és a rendszer szerint a játékos még mindig abban az előre meghatározott zónában van, ahol elvileg a füst láthatatlanná teszi.

Ennek gyökeres ellentéte az a szituáció, amivel szintén lehet találkozni, és hasonlóan kellemetlen. Alapvetően arról van szó, hogy a füsttel teli területen teljes vakságra kényszeríteni a mesterséges intelligenciát igen kockázatos, így a fejlesztők inkább az ellenfelek úgymond látását korlátozzák. Ez a program szintjén azt jelenti, hogy a virtuális karakterek nézőpontjából rengeteg sugár indul ki, viszont ezek jó részét a füstként jellemzett területen eldobja a rendszer. Ez reális eredményt ad akkor, ha közel kerülünk az ellenfélhez, viszont magával hozza azt a kellemetlenséget is, hogy a legnagyobb füstben is eltalálhatja a játékos virtuális mását egy pásztázó sugár, aminek a legrosszabb esetben egy halálpontos fejlövés a következménye.

Ezek az apró problémák annyira általánossá váltak, hogy a legtöbb játékos már nem is érzékeli, de a fejlesztők rengeteg területen kutatják a jobb játékélmény lehetőségét, márpedig a jobb mesterséges intelligencia egyértelműen segíthet ezt javítani. Ehhez viszont pontosabb adatokkal kell táplálni a gépi ellenfeleket, és az integráció rengeteg területen pont ezt teszi lehetővé. A részecskeeffektek például még az adott jelenetbe visszaírhatók, vagyis a gép pontosan ugyanazokat az információkat kapja meg, amiket a játékos a képernyőn lát. Persze a mesterséges intelligencia nem kap képi megjelenítést, viszont a visszaírt adatokból igen pontos képet festhet le a rendszer például a füstről, így sokkal több adat áll rendelkezésre ahhoz, hogy a mesterséges intelligencia megfelelően döntsön egy-egy szituációban. Ez kétségtelenül az egyik legegyszerűbb példa arra, hogy a fejlesztők miért szeretnének mély integrációt, és ebből könnyen kitalálható, hogy más területeken is igen drámai lehet az újítások hatása. Ami a legfontosabb, hogy nem érdemes már csak a grafikára gondolni, ha az integrált grafikus vezérlőről beszélünk, mivel az sokkal komolyabb feladatokat kap.

A visszaírásnak a fizikai szimulációk szempontjából is szerepe lesz. A GPGPU alkalmazása a fizika számításához nem újdonság, de az aktuális rendszerek csak vizuális tartalomként értelmezik ezt, vagyis mondhatjuk úgy is, hogy grafikai effektekről van szó. Az új konzolokon a fizika szimulálására úgy lesz lehetőség, hogy még ugyanabban a jelenetben megkapja a rendszer a szükséges információkat, ami lehetőséget ad arra, hogy az IGP-vel gyorsított fizikai hatások a játékmenetet is befolyásolják, ami dedikált grafikus processzorral nem igazán valósítható meg.

Egy játékban a rendezésre is viszonylag sokszor van szükség, ami számítással jár ugyan, de végső soron segíti az adott képkocka hatékony leképzését. Számos GPGPU algoritmus létezik a rendezés szempontjából, melyek a CPU-n futó megoldásokhoz képest számottevően gyorsabbak. Az meg főleg segít ennek az elvnek, hogy a konzolok APU-jai egységes címteret használnak, aminek hála a GPGPU-s rendezés eredményét azonnal látja a processzor.

A mesterséges intelligencia által irányított egységek útkeresése is egy igen érdekes terület. A mai játékokban nincs túl sok szereplő az adott jelenetekben, leszámítva persze a stratégiai játékokat, de azok amúgy sem tudták megvetni a lábukat a konzolokon. Viszont a jövőben az életterek szimulálása igencsak megváltozhat, hiszen elsősorban azért nincs ezernyi nem játékos karakter egy jelenetben, mert igen nehéz lenne ezeket megfelelő sebességgel szimulálni. Hát még ha ezekbe a virtuális szereplőkbe saját életet táplálnak, azaz nem csak értelmetlen részei a világnak, hanem mindenki tart valahova, ami nagymértékben növelné a realizmust. A legnagyobb probléma itt, hogy a komplex terepek esetében a sok karakter útkeresése igen számításigényes, amit a mai központi processzorok szimplán nem bírnak el. A grafikus vezérlő viszont sokkal több számítási teljesítménnyel rendelkezik, és ami a legfontosabb, hogy pár programszál helyett több tízezret futtathat. A konzolokban gyakorlatilag egy szál a grafikus multiprocesszorokon hozzárendelhető egy egység útkereséséhez, így rendkívül gyorsan kiszámítható akár ezer jelenetben szereplő karakter számára is az ideális útvonal.

A tartalom dekódolásának szempontjából is fontos szerep juthat az integrált grafikus vezérlőknek. Ez főleg abból a szempontból igaz, hogy a játékok egyre részletesebb textúrákat kapnak, miközben a tárhely azért nem növekszik robbanásszerűen, így esetenként szükséges alkalmazni valamilyen tömörítést. Ez persze kellemetlen, hiszen a kódolt textúraformátumot esetleg a hardver nem kezeli, ami rögtön ahhoz vezet, hogy a processzornak a tartalmat dekódolnia kell egy támogatott formátumra. Ezt viszont egységes címtér mellett megteheti a grafikus vezérlő is, hiszen nagyságrendekkel nagyobb számítási kapacitással rendelkezik, ráadásul az egész folyamat nagyon jól párhuzamosítható. A nagy teljesítménynek ráadásul komoly jelentősége lehet a jövőben, hiszen észrevehető, hogy a fejlesztők alapvető célkitűzése, hogy a lehető legtöbbször hanyagolják a töltőképernyőt. Ehhez rendkívül hatékony streaming rendszer szükséges, ahol a tartalom dekódolásának sebessége nagyon fontos lesz. Akár olyan játék is elképzelhető, ahol lényegében teljesen mellőzhető a töltőképernyő alkalmazása.

A fentebb leírtak persze csak példák, amelyeket relatíve egyszerű bevetni. Ennél sokkal komplexebb feladatok is megoldhatók, így például a sportjátékokban bevezethető az izomzat szimulációja, illetve az APU-k számítási kapacitásának kihasználásával következetesebb és valósághűbb lehet a játékosok mozgása, illetve reakciójuk egymásra. Extrémebb lehetőség lehet az időjárási elemek valós idejű szimulálása, így például a széllel való játék, ami szintén új lehetőségeket teremthet a játékokban.

Mi lesz a PC-vel?

Az előbbi oldalak olvasása után sokan tehetik fel azt a kérdést, hogy mi lesz a PC-vel? Az új konzolok kétségtelenül PC-s architektúrát használnak, de a lehetőségeket az API nem korlátozza, illetve az integráció mélysége is igen extrém. A szomorú valóság, hogy jelenleg nincs olyan PC-s konfiguráció, ami képes lenne az Xbox One és a PlayStation 4 technikai képességeivel vetekedni. Bizonyos korlátok ráadásul a PC-n igen sokáig megmaradnak, mivel nem a hardverrel van a gond, hanem a PC-s API-k fejlődésével.

Az egész helyzet egyébként rendkívül komikus, hiszen a hasonló alapok miatt most lehet a konzolokat a legjobban összehasonlítani az aktuális PC-s konfigurációkkal, így csupán a számokat figyelembe véve igen gyorsan le lehet vonni azt a következtetést, hogy ezek a konzolok nem is annyira gyorsak, főleg a processzormagok teljesítményét figyelembe véve. Viszont mélyebben vizsgálva a dolgokat – kilépve a számok bűvköréből – már látható, hogy a konzolok még sosem voltak ekkora előnyben a PC-khez képest. Ez persze tudásbeli és technológiai előny, de jelenleg erre van a legnagyobb szükség.

Amit a sajtó általánosan rebesget, hogy az AMD alapvető előnybe kerül a PC-s játékosok körében, hiszen a konzolokba is ők szállítják az architektúrát. Erre a cég persze rá is játszik, így minden nyilatkozatukban kiemelik ezt a tényt, de nem szabad ennyire mereven értelmezni a helyzetet. Természetesen logikus azt hinni és leírni, hogy a konzolra optimalizált programok az AMD-nek automatikusan előnyt jelentenek, de ez a gyakorlatban nem így működik.

Ami a legfontosabb ebből a szempontból, hogy az általánosítást el kell felejteni. A különböző PC-s portok között ugyanis sok eltérés lehet. Nem elhanyagolható módon az AMD ugyanúgy küzd a PC-s API-k által okozott korlátokkal, vagyis a PC-re mindenképp másképp kell optimalizálni.

Alapvetően a portolás szempontjából több esetet érdemes megkülönböztetni. A legrosszabb eshetőség, ha az adott játék kihasználja azokat az extrákat, amelyeket a konzolok esetében a mély integráció jelent. Ez PC-n ma lekövethetetlen. Sajnos bevallottan lesz ilyen játék, méghozzá a FIFA 14. Erről az EA Sports már el is mondta, hogy a PC-s verzió nem kapja majd meg az új Ignite motort, mivel a játékosok által birtokolt számítógépek jó része képtelen azt futtatni. A játék egyébként kisebb korlátozásokkal működésre bírható az AMD Trinity és Richland APU-kon, de a teljes értékű porthoz az év végén érkező Kaveri APU szükséges (modern VGA-val társítva), ami nem mellesleg pontosan azokat az újításokat vezeti be, amelyeket az új generációs konzolok APU-i kínálnak a fejlesztőknek. Sajnos a helyzet nem egyszerű az EA Sports számára, hiszen óhatatlan, hogy a játékosok üzleti megfontolást sejtenek a korlátozások mögött, de tulajdonképpen teljesen érthető, hogy a portolásnál azokat a gépeket veszik számításba, amelyekkel a játékosok zöme rendelkezik, így a PC-s FIFA 14 (az Xbox 360-hoz és a PlayStation 3-hoz hasonlóan) a régebbi motorra épül.

Kedvezőbb lehet a helyzet, ha az adott játék nem használja ki az új konzolok extra képességeit, hiszen ilyenkor a PC-s port sem lesz olyan problémás. Bizonyos dolgokat lehet, hogy át kell benne írni, de ez bőven vállalható minden érintett számára. Itt is elsősorban a grafikai effektekre kell gondolni, hiszen ha a konzolon a fejlesztő túlzásba viszi a compute shaderek használatát, akkor az a PC-s API-k esetében a korlátok átlépését jelentheti, így bizonyos algoritmusokat át kell dolgozni, vagy rosszabb esetben szimplán mellőzni kell az adott effektet. Ráadásul itt van is egy alapvető érdekellentét is a PC-s versenyzők között, hiszen az AMD nagyon szeretné, ha a fejlesztők a compute shadereket áthoznák PC-re, míg az NVIDIA például nagyon nem szeretné ezt. Ez is befolyásolhatja egy játék portolását.

Végül meg kell említeni azt is, ha a PC-s portot a fejlesztő félvállról veszi. Ezt egyetlen PC-s játékos sem szereti, de ma is van ilyen, és gyakorlatilag tényként kezelhető, hogy a következő generációs konzolok esetében is lehet rá számítani. Ilyen esetben az AMD valóban előnyben lesz, mivel a PC-kbe szánt GCN architektúrára épülő Radeonok képességei megegyeznek a konzolos verzióval, ami nagyon kedvez majd a változtatások nélkül, vagy kis módosításokkal portolt shadereknek.

A konzol és a PC csatája humoros formában
A konzol és a PC csatája humoros formában [+]

Látható tehát, hogy az AMD előre beharangozott előnye nem általános, hanem a szituációktól függ. Attól tehát egyáltalán nem kell tartani, hogy a GeForce használhatatlan lesz a PC-s játékosok számára. Jó portok mellett lényegében senkit sem ér majd hátrány, a kifejezetten rossz portok pedig felfoghatók kivételnek, melyek erősíthetik a szabályt.

Ami kellemetlenebb helyzet, hogy a mély integrációt minden cégnek le kell követnie, mivel ha elsőre nem is, de a második hullámban számos játék kihasználhatja majd a konzolok extra képességeit ilyen téren. Szerencsére már tudni lehet, hogy nem csak az AMD tervez ilyen rendszert a Kaveri APU-val, hanem az NVIDIA is bejelentette, hogy a Maxwell kódnevű architektúrát kifejezetten a mély integrációhoz tervezi, igaz, ARMv8-as processzormagok mellé. Utóbbi viszont nem feltétlenül jelent rosszat, hiszen a Microsoft biztosan fejleszt hozzá megfelelő Windows operációs rendszert, illetve a fejlesztők számára sem jelenthet túl nagy befektetést az ARM-os portok elkészítése. Az Intel helyzete a legbonyolultabb, hiszen számukra a mély integrációt a néhai Larrabee utódjának tekinthető MIC architektúra beépítése jelenti. Információink szerint ez a 2015-ben érkező Skylake-ben megtörténik, viszont erről többet még nem lehet tudni.

Érdekes lehet az a szituáció is, amit az ARM-os Windows idézhet elő. Ha a Microsoft jól keveri a kártyákat az operációs rendszer fejlesztésével, akkor az ARM-os réteget teljesen rászabadíthatják erre a piacra, hiszen a Qualcomm, az ARM, illetve lényegében mindenki mély integráción dolgozik.

Ami biztos, hogy az előrendelési adatok alapján a Sony PlayStation 4 nagy sikerre számíthat, de úgy gondoljuk, hogy a Microsoft Xbox One is megtalálja majd a számításait, elsősorban az Egyesült Államokban. A vevőket természetesen az exkluzív tartalmak érdeklik majd, így hosszúra nyúlt cikkünkben a technikai részletek csak érdekességként hatnak, de túl nagy befolyásuk semmiképp sem lesz a konzolpiaci eladásokra.

Abu85

Azóta történt

Előzmények

Hirdetés