Hirdetés

Ideális a virtuális valósághoz a SteamOS és a Mantle API

A virtuális valóság egyre forróbb témává válik, és a koncepcióról társoldalunk, az IT Café már írt is egy cikket. Ebben az Oculus Rift nevű termékkel közelebbi ismertséget is kötöttünk, így tapasztalatokat is megoszthattunk, de a rendszer működése nem olyan egyszerű, amilyennek egy külső szemlélő számára látszik. Valójában a virtuális valóságot a legnehezebb megvalósítani a mai rendszereken, mivel rengeteg buktatója van, és ezek zöme a szoftveres oldalról érkezik. A legfőbb gond a késleltetés, ideértve az adott operációs rendszer és grafikus API nem ideális működését. Ezeket ugyanis ma nem úgy tervezték, hogy valaha is lényeges tényező lesz a virtuális valóság. Elvi szinten a mai szoftveres ökoszisztéma arra bőven jó, hogy a felhasználó a játék közben a beviteli eszközön kiadott parancsot úgy érzékelje, hogy ennek azonnal eredménye legyen. Nyilván a gyakorlat ettől eltér, hiszen a parancs kiadása és az ezt feldolgozó jelenet, valamint az abból készített képkocka között viszonylag sok idő eltelik, de emberi mércével ez reálisan nem, vagy csak nagyon ritkán érzékelhető.

A virtuális valóság megalkotása azonban bevisz egy újabb tényezőt a rendszerbe, amihez már nehezebb alkalmazkodni. Gyakorlatilag arról van szó, hogy a fejmozgást követve keletkezik az az információ, ami alapján el kell helyezni a kamera pozícióját a megfelelő képkocka előállításához. Ez egyrészt egy beviteli adat lesz, vagyis gyakorlatilag a beviteli eszközön kiadott parancsok kiegészülnek egy új tényezővel, másrészt a fejmozgás tulajdonképpen éppúgy reakció az eseményekre, mint ahogy a játékvezérlő gombjainak nyomogatása. Utóbbi esetében azonban a fejmozgás szempontjából a felhasználó sokkal direktebb élményben részesül, vagyis jobban fogja érzékelni, hogy a mozgást csak egy apró késés mellett követi le a számítógép. Ez teljesen logikus, hiszen a beérkező adatokat előbb fel kell dolgozni, és csak ezután lesz annak eredménye.

Hirdetés

A virtuális valósággal rengeteget foglalkozó John Carmack szerint 20 ezredmásodperc az a maximális a késés, amit az ember nem, vagy csak nehezen érzékel. Ezzel sokan egyetértenek, és általános nézetté vált, hogy az Oculus Rifthez hasonló eszközök 20 ezredmásodpercen belül reagáljanak a fejmozgásra. Ezt azonban ma könnyebb mondani, mint megvalósítani, ugyanis a mai konfigurációk számottevően nagyobb késéssel dolgoznak. Jelen pillanatban tehát inkább az 50 ezredmásodperces késleltetés elérése a cél, ami még elfogadható eredményt ad, de jobban odafigyelve a késés itt már érzékelhető. A probléma komplex, így az egésznek éppúgy része a szoftveres alap, mint a hardver. Utóbbi szempontból a virtuális valóságra tervezett szemüvegen kell a lehető legjobb apró kijelzőket használni. Jó eséllyel az OLED-re esik majd a választás, mert annak vannak a legjobb paraméterei a késleltetés szempontjából, és a rendszer mentes számos olyan problémától, amitől az LCD technológia még ma is szenved.

A PC-n belül már jóval nehezebb megoldást találni a problémákra. A gond, hogy az aktuális operációs rendszereket és grafikus API-kat abszolút nem úgy tervezték, hogy jó minőségű virtuális valóságot teremtsenek a játékosnak. A Valve például pont ezért ecsetelte, hogy a SteamOS működését átszabják majd a minél alacsonyabb késleltetés érdekében, mert már készülnek az Oculus Rifthez hasonló eszközök érkezésére. A grafikus API-kkal ugyanakkor nem tudnak mit kezdeni, mert sem a Microsoft, sem pedig a Khronos Group nem foglalkozik ezzel a gonddal. Jelen pillanatban mindkét érintett csak távolról szemléli virtuális valóság irányába történő lépéseket, így a DirectX-et és az OpenGL-t az elmúlt években nem készítették fel erre.

Az API-k és az aktuális driver modellek szempontjából a legnagyobb probléma, hogy a grafikus processzor memóriája el van rejtve a programozó elől, ami jelentős előrelépést kínáló optimalizálások előtt zárja le a kaput. Ez persze nyilván okkal alakult így, hiszen nem örülne annak senki, ha egy játék miatt összeomlana az operációs rendszer, de a virtuális valóság tökéletesítéséhez egyszerűen túl sok a korlát. Régóta téma, hogy több kontrollt kellene a fejlesztők kezébe adni, így például a grafikus motor akár közvetlenül is elérhetné a grafikus processzor memóriáját, vagy annak nagy részét. Ez régen nyilván elképzelhetetlen volt, de a mai hardverek már nem olyan buták. Az elmúlt héten bejelentett Mantle elsősorban ott újít, hogy a fejlesztők kezébe adja a memória egy részének közvetlen elérését. Természetesen lesz egy alapszintű érvényesítési procedúra, de a hardver oldalán igen biztonságos a GCN architektúra, hiszen a VRAM-on túl még a lapkán belüli helyi adatmegosztásra (LDS) vonatkozó memóriák is virtualizálva vannak. Gyakorlatilag a fejlesztők a Mantle API-ban aszinkron memóriamásolásokkal is dolgozhatnak a grafikus futószalag működésének leállítása nélkül, nagyon alacsony késleltetésű ütemezés mellett. Ez rendkívül kedvező lesz a Oculus Rifthez hasonló rendszerekhez.

A Mantle különösen akkor előnyös, ha a felhasználónak két grafikus processzora van (CrossFire vagy SLI). Manapság a virtuális valóság igen kedvezőtlen eredményt mutat fel az előbbi rendszereken, mivel jóval magasabb a rendszer késleltetése az AFR elvű működés miatt. Gyakorlatilag ezért ma az Oculus Rift nem igazán működőképes egynél több grafikus processzorral. Elvi szinten nyilván nincs akadály, de a felhasználói élmény egyszerűen nem lesz jó. A Mantle esetében lényeges tényező, hogy az API-t szándékosan úgy tervezték, hogy direkten kihasználja a sztereó 3D sajátosságát, hiszen minden jelenetről két képkockát kell készíteni a két szem számára, így az egyes képkocka párok felosztható a két grafikus processzor között. Némi trükközéssel ugyanez megoldható a DirectX és az OpenGL API-n keresztül, csak nem olyan hatékonyan, mint a Mantle-ön, amit alapjaiban felkészítettek erre a feldolgozási formára.

A virtuális valóság amellett, hogy érdekes irány, még mindig nagyon nehézkes. Ha a hardver oldalán meg is kapjuk a kellően alacsony késleltetést, akkor is sok múlik az operációs rendszeren, az alkalmazott grafikus API-n és végső soron az adott programba épített optimalizáción. Utóbbit nem a sebességre, hanem a DirectX és az OpenGL API, valamint az alkalmazott driverek késleltetésének csökkentésére kihegyezve, többek között elkerülve a mai grafikus meghajtók általános optimalizálásait a rajzolási parancsok agresszív pufferelésére vonatkozóan. Manapság mindegyik cég ilyen elvű működést alkalmaz a grafikus eszközillesztőkben, mivel növeli az elérhető sebességet, de ezzel párhuzamosan növeli a késleltetést is, ami mai viszonylatban ugyan nem lényeges, viszont a virtuális valóság szempontjából már nagyon is az.

Ami jó hír, hogy a Valve SteamOS, illetve az AMD Mantle API egy lépés lesz a koncepció megvalósulása felé, de jóval átfogóbb megoldások kellenének, hiszen a játékosok többsége még mindig a Windows operációs rendszereket nyüstöli, valamint nem mindenki rendelkezik GCN architektúrára épülő Radeonnal. Ennek megfelelően az irány ugyan jó, de még messze vagyunk a céltól, és különösen a virtuális valóság széleskörű elterjedésétől.

Hirdetés

Fotóznál vagy videóznál? Mutatjuk, melyik okostelefon mire való igazán!

PR Vásárlás előtt érdemes megnézni, mit kínálnak az aktuális telefonok, ha igazán ütős képeket vagy profi mozgóképeket szeretnénk készíteni.

Azóta történt

Előzmények