Virtuální realita a požadavky na grafické karty

Boj o nízké latence

Jak už jsme si dnes řekli a mnohokrát zdůraznili, u virtuální reality nejde ani tak o hrubou snímkovou frekvenci, ale zejména o nízké latence, tedy dobu, za kterou je snímek ve VR pipeline vytvořen. Pro virtuální realitu je latence snímku tak zásadní, že výrobci grafických čipů vytvářejí svá vlastní speciální API a SDK, které častokrát odebírají některé služby OS Windows a pro snížení latence komunikují raději s VR headsetem přímo na úrovni hardware.

Takovýmito speciálními SDK jsou například LiquidVR od společnosti AMD a GameWorks VR od společnosti Nvidia. Obě tyto SDK jsou si velice podobné a samozřejmě i účel je ten samý, nicméně i zde nějaké rozdíly najdeme. My se na některé funkce těchto SDK dnes podíváme a samozřejmě na rozdíly v implementaci obou společností upozorníme. Začněme nejdříve tam, kde se funkčnost těchto dvou SDK od sebe liší.

Time Warp

Co to je Time Warp? Představte si, že máte na hlavě nasazen VR headset, díváte se před sebe a najednou hlavou otočíte doleva. Spustí se samozřejmě řetězec událostí. Senzory registrují pohyb a vysílají nové souřadnice v prostoru do PC, CPU připraví snímek a GPU začne snímek urychleně renderovat, protože doba obnovovací frekvence HMD se rychle blíží a musí to stihnout. Co se ale stane, když to GPU nestihne? Stejně jako u hraní na monitoru počítače je pro zobrazení na MHD použit opětovně snímek starý (neaktuální). Zatímco při hraní na monitoru počítače nám to nějak zvlášť nevadí, u virtuální reality se to stává velkým problémem. Vzniká takzvaný "judder", kdy uživatel cítí, že ačkoliv se v prostoru pohnul, žádná adekvátní reakce nenastala, následuje ztráta orientace v prostoru virtuální reality a u některých jedinců také nevolnost. Aby k tomuto jevu nedocházelo, je tu náš Time Warp, který pracuje na jednoduchém principu přepočítání starého snímku.
Pokud GPU při své práci zjistí, že tento nový snímek nestihne vyrenderovat včas do obnovovací frekvence HMD, svou práci okamžitě přeruší, vezme raději snímek starý (již hotový předešlý), přečte z registru senzorů aktuální polohu VR headsetu v prostoru a pomocí výpočetního shaderu upraví vzhled tohoto starého snímku podle aktuálních dat senzorů. Vlastně se tedy jedná o umělé dopočítání snímku. HMD obdrží nový (starý ale transformovaný) snímek, žádný judder se nekoná, uživatel je spokojen a celá tato nemilá situace je zachráněna.
Bohužel u Time Warp vznikají první rozdíly mezi grafickými kartami AMD a Nvidia. Kdo četl náš článek o asynchronní shaderech už asi dobře ví, o čem mluvíme. Zatímco u grafických karet architektury GCN bude probíhat vše hladce a dokonce díky podpoře asynchronních shaderů v době, kdy bude probíhat výpočet Time Warp snímku, můžou tyto grafické karty pracovat souběžně již na novém snímku, u Keplerů a Maxwellů tu vzniká malý problém. To, že současně s Time Warp nebudou moci pracovat na dalším snímku, je celkem až podružné, horším problémem je to, tyto grafické karty nedisponují tak rychlým preemption, tedy možností práci na snímku okamžitě přerušit a spustit výpočet Time Warp. Preemption je zde řešeno pouze na úrovni ještě neprobíhajících úloh ve frontě, nikoliv úloh již spuštěných. Jak moc to bude v reálné praxi vadit, ukáže samozřejmě až čas, dosavadní ohlasy vývojářů VR však ale nejsou příliš povzbudivé. Uvidíme tedy a raději půjdeme dále.

Nvidia Multi-Res Shading

Čím se naopak společnost Nvidia u svých grafických karet a VR pochlubit může, je technologie Muti-Res Shading. Jde o to, že VR headsety využívají před vlastními displeji ještě optické čočky, které dopomáhají vjemu širšího zorného pole lidského zraku. Obraz, který je vysílán na displej, tedy nemůže být takový, jaký známe z našich monitorů, ale musí na něm být provedena kompenzace zkreslení optického lomu čoček.
Grafická karta se o tuto kompenzaci samozřejmě musí postarat. Při této kompenzaci jednak dochází ke ztrátě některých pixelů na okraji obrazu a také lidské oko tyto okraje nevnímá tak ostře jako střed obrazu.
Toho využívá právě technologie Multi-res Shading, která obraz při procesu kompenzace rozdělí do 9 sekcí (viewports) s různými požadavky na rozlišení. Prostřední viewport je renderován v rozlišení nativním (nejvyšším), kdežto na okrajové viewporty je pak použito nižší rozlišení. Protože je ve výsledku pracováno s nižším počtem pixelů, výsledkem je ušetření práce pixel shaderu a samozřejmě s tím spojená nižší latence tvorby snímků. Dle společnosti Nvidia je díky funkci Multi-res shading výkon pixel shaderu navýšen 1,3 až 2x.

Latest Data Latch

Latest Data Latch je funkcí LiquidVR, která se zaměřuje především na snížení input lagu a zdánlivé latence. V případě klasické pipeline CPU společně s připraveným snímkem zasílá na GPU také další informace (Constant buffers), které grafická karta využívá k vlastnímu renderingu jako parametry. V případě virtuální reality tu mohou být uloženy údaje ze senzorů o poloze VR headsetu, podle kterých následně grafická karta vyrenderuje patřičný obraz.
Pokud tyto informace o poloze VR headsetu zasílá CPU, nějakou dobu se v pipeline nutně musejí zdržet a v době, kdy s nimi začne pracovat GPU, jsou již většinou zastaralá a samozřejmě i vyrenderovaný snímek je zastaralý také, protože neodpovídá nejaktuálnější poloze VR headsetu. Proč by si ale grafická karta nemohla přečíst data ze senzorů o poloze VR headsetu sama těsně před tím, než začne s renderováním? Nový snímek by pak byl vždy aktuální a byla by v něm promítnuta vždy poslední a nejaktuálnější pozice VR headsetu v prostoru. A přesně tohle má na starosti funkce Latest Data Latch.

To by bylo k rozdílům mezi grafickými kartami a funkčnostmi SDK společností AMD a Nvidia asi tak vše, tedy pokud jsme na něco nezapomněli. Zbytek funkcí SDK LiquidVR a GameWorks VR už jsou pak společné, takže se na ně pojďme podívat.

Direct to Play (AMD), Direct Mode (Nvidia)

Současné operační systémy nemají speciální podporu pro HMD virtuální reality a snaží se displeje HMD spravovat podobným způsobem jako klasické monitory včetně přidávání dalších abstraktních vrstev OS a Power managementu. To by samozřejmě mohlo způsobovat různé problémy při zobrazení virtuální reality, a proto je role operačního systému při práci s HMD zcela odstraněna. Grafické karty tak komunikují přímo s HMD. Úplným vyloučením OS jsou pak dosahovány nižší latence při odesílání obrazu na HMD a dovolují i takové další techniky vykreslování, jako je Front Buffer Rendering, kdy je pro zobrazení využíváno pouze jediného prezentačního bufferu GPU v době VBlank intervalu (snížení latence a input lag).

Affinity Multi-GPU (AMD), VR SLI (Nvidia)

Samozřejmě nejjednodušším a nejefektivnějším řešením, jak zvýšit výkon a snížit latence při renderování snímků zabijáckých požadavků virtuální reality, je rozdělení práce na více GPU. Při využití dvou grafických karet se pak každá jedna může starat samostatně o snímky pro jediné oko. Meze se samozřejmě nekladou ani při zapojení více grafických karet, kdy se o každé oko může starat více grafických karet. O to, že by náhodou procesor svou práci pro všechny zapojené grafické karty nestíhal, se rozhodně bát nemusíte. Prakticky všechna data a příkazy (Draw calls) jsou totiž stejné pro všechny GPU a liší se pouze úhlem pohledu každého oka. Samozřejmě Multi-gpu řešení je pro každého uživatele dražší záležitostí, nicméně pro potřebný výkon ve virtuální realitě nesmírně účinné. Zdá se tedy, že se nám začíná opět rozednívat nad Multi-GPU řešením, samozřejmě ale v jiné podobě než v té dosavadní AFR (Alternate Frame Rendering).


Ze souhrnné tabulky podporovaných funkcí je patrné, že mírnými favority pro využití virtuální reality jsou grafické karty společnosti AMD a jejich LiquidVR. Nezapomeňte však, že ještě není všem dnům konec a než se na trhu objeví první finální VR headsety a hry, může být vše úplně jinak.