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.

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.