Negatív késleltetést fejleszt a Google a Stadiához

A Google még márciusban mutatta be a Stadia nevű, felhős játékszolgáltatását, amelyről a linkelt hírben részletesen beszámoltunk, az E3-on pedig a részletekről is lerántották a fátylat. Ráadásul a cég az efféle rendszerek tipikus problémájára, vagyis a késleltetésre is gondolt, ugyanis a hardvereket a peremhálózati szerverekbe építik, hogy szétszórtan legyenek megtalálhatók a világon, így pedig egész jó eredményeket lehet elérni ebből a szempontból is. Ezt a Google-ön kívül maximum a Microsoft tudja megcsinálni, másnak viszont nincs olyan, világszinten kiépített szerverhálózata, amivel realitás lehetne az alacsony késleltetés.

A nagy kérdés jelenleg az, hogy mi az az érték, amitől a késleltetés már jónak mondható. Erre a tipikus válasz a minél alacsonyabb paraméter, ugyanakkor ebből a szempontból még a peremhálózatokba épített konstrukcióknál sem igazán hozható egy lokális szinten kiépített rendszer képessége, maximum nagyon megközelíthető. Alapvetően a hétköznapi játékosoknak ez jó lehet, tehát maga a szolgáltatás piacképes, de ahhoz, hogy megnyerjék a játékosok keménymagját, lényeges fejlesztésekre van szükség.

A Google dolgozik is egy ilyen fejlesztésen, amelyet negatív késleltetésnek neveznek. Első olvasatra azt gondolhatná a felhasználó, hogy ilyen nem létezik, de valójában megvan a tudományos alapja, és a Microsoft korábban már beszélt egy hasonló, DeLorean nevű rendszerről. A keresőóriás ezt az ötletet szeretné megvalósítani a gyakorlatban. Madj Bakar, a Google mérnöki részlegének az alelnöke, az Edge Magazine számára elmondta, hogy egy vagy két éven belül a felhőben futtatott program késleltetését jobbnak érezheti majd egy felhasználó a lokális gépen futó verzióhoz viszonyítva, legyen a helyi rendszer akármilyen erős.

A technikai alap tekintetében arról lenne szó, hogy a felhasználó következő mozdulatait megpróbálja megtippelni a rendszer, így már azelőtt elkészítheti a szükséges képkockát, mielőtt a bemeneti adatokat megkapná. Innen ered a név: negatív késleltetés. Ez mind jól hangzik, és természetesen kivitelezhető, hiszen a Microsoft ezt már tesztelte, a visszajelzések pedig kiválóak voltak.

A fentiek alapján viszont felmerülhet a kérdés, hogy ha ez ilyen nagyszerű, akkor miért nem működik már? Na ez az, amiről a Google nem beszélt, ugyanis a rendszer előnyei vitathatatlanok, és ebből a felhasználó tényleg csak jót lát, viszont az üzemeltető számára rendkívül sok a hátránya. Ahhoz, hogy a felhasználó jó képkockát kapjon a kliensén, sokkal több képkockát kell számolni a szerver oldalán. A predikciónak ugyanis pontosnak kell lennie, és ennek érdekében a gép több vasat fog úgymond a tűzben tartani. Ezeket el is küldi a kliensnek, amely később kap egy üzenetet, hogy az elküldött bementi adatok alapján melyik képkocka lesz végül az, amelyiket meg kell jeleníteni. Két dolog kell tehát a negatív késleltetés működéséhez: a szerver oldalán nagyobb számítási kapacitás, sokkal nagyobb, nem csak pár százalékkal, illetve a kliens felé jobb internetelérés, elsődlegesen a letöltési sebességet tekintve, hiszen jóval több képkocka fog érkezni egységnyi idő alatt. Utóbbi a kisebbik baj, tekintve azt, hogy a vezetékes internetelérési lehetőségek igencsak fejlődnek, és lassan a gigabites kapcsolat sem számít túl extrának, amelynek bőven elégnek kell lennie. Előbbi viszont nagy gond, mivel az efféle felhős játékszolgáltatásoknál ki kell termelni a szerverek üzemeltetését, és minél több felhasználó veszi igénybe az adott szervert, annál gazdaságosabb az egész szolgáltatás működése. A negatív késleltetés viszont pont, hogy ez ellen dolgozik, mivel már koncepcióból úgy van felépítve, hogy a szerver erőforrásait gyakorlatilag pazarolja, méghozzá egy probléma kezelése érdekében.

A jövőben egyébként ez a gond részben kezelhető lehet, ha a videojáték-motorokat felkészítik a felhőn belüli munkamegosztásra, figyelembe véve a kliensoldali igényeket, vagyis nem kell minden egyes új képkockához új jelenetet számolni. Ennél is kedvezőbb megoldás egy olyan grafikus alrendszer, ahol a GPU-k egy igen gyors interfésszel össze vannak kötve, és a beérkező jelenetet egységesen kezelik a geometria kiszámításáig, majd közvetlenül a raszterizálási fázis előtt válik szét a munka több részre, amivel a szerver sok számítást megspórol, viszont így is több kamera nézőpontjából képezi le a jelenetet. Ehhez hasonló hardvereket azonban nem igazán gyártanak szerverbe, mert extrém igénynek számít, viszont a Google kellően nagy cég ahhoz, hogy saját maga – egy-két gyártót kiválasztva – összerakja a negatív késleltetéshez szükséges hardveres alapot. Ez azonban az üzemeltetés szintjén mindig drágább lesz, mint a normál feldolgozás, tehát elképzelhető, hogy a funkcióért extra havidíjat kell majd fizetni.