我學(xué)院：VR延遲優(yōu)化方法

學(xué)游戲就上我學(xué)院Unity3D|Cocos|php|HTML5|Java|ios|Android|C#|AS3|UI設(shè)計(jì)|原畫(huà)設(shè)計(jì)|動(dòng)漫美術(shù)|游戲策劃VR延遲優(yōu)化方法

VR中的”延遲”,特指”Motion-To-PhotonLatency”,指的是從用戶運(yùn)動(dòng)開(kāi)始到相應(yīng)畫(huà)面顯示到屏幕上所花的時(shí)間.

這中間經(jīng)過(guò)了大概這么幾個(gè)步驟:

傳感器采集運(yùn)動(dòng)輸入數(shù)據(jù)

采集到的數(shù)據(jù)進(jìn)行過(guò)濾并通過(guò)線纜傳輸?shù)街鳈C(jī)

游戲引擎根據(jù)獲取的輸入數(shù)據(jù)更新邏輯和渲染視口

提交到驅(qū)動(dòng)并由驅(qū)動(dòng)發(fā)送到顯卡進(jìn)行渲染

把渲染的結(jié)果提交到屏幕,像素進(jìn)行顏色的切換

用戶在屏幕上看到相應(yīng)的畫(huà)面

當(dāng)然,實(shí)際上還有很多細(xì)節(jié)問(wèn)題,比如屏幕上的像素并不是同一時(shí)間切換的,可能面上面的那行先切換,再一行行更新到最下面的,在這里就不糾結(jié)這些細(xì)節(jié)了.

這其中的每一個(gè)步驟都會(huì)產(chǎn)生一定的延遲,而目前公認(rèn)的大眾能接受的延遲是20ms以下,這基本上可以做為衡量一個(gè)VR頭顯是不是合格的一個(gè)標(biāo)準(zhǔn).雖然20ms是非常短的時(shí)間,但通過(guò)努力還是可以達(dá)到的,主要有這么幾個(gè)思路:

1、硬件層面的優(yōu)化

提升傳感器的采樣頻率,減少刷新率與傳感器頻率的同步等待時(shí)間消耗

提升傳感器的精度,減少對(duì)采樣數(shù)據(jù)進(jìn)行穩(wěn)定性過(guò)濾產(chǎn)生的延遲

采用有線傳輸也有一部分原因是出于延遲的考慮

屏幕使用OLED替代LCD,減少像素顏色切換的時(shí)間

提升屏幕刷新率,主流的屏幕是60Hz,那每幀就是16.67ms;如果提升到90Hz,那每幀就是11.11ms

大部分的手機(jī)VR產(chǎn)品在延遲上都是不合格的,最明顯的表現(xiàn)就是轉(zhuǎn)頭時(shí)的畫(huà)面不連續(xù)/抖動(dòng)/殘影等:

市面上的手機(jī)采用OLED屏的還是少數(shù),比如iPhone配個(gè)VR殼子那延遲就很感人

如果依賴手機(jī)的陀螺儀進(jìn)行轉(zhuǎn)向模擬,其精度和頻率遠(yuǎn)遠(yuǎn)達(dá)不到要求

手機(jī)屏幕目前都是60Hz的刷新率,在延遲上本身就受限

刷新率的提升

假設(shè)刷新率為60Hz,并不是代表每幀就有16.67ms的延遲,而是說(shuō)屏幕圖像每16.67ms才更新一次,渲染選項(xiàng)中的”垂直同步”的概念就是來(lái)源于此.這就對(duì)我們提交渲染畫(huà)面的時(shí)機(jī)要求非常高,如下圖:

為了方便計(jì)算,這里先假設(shè)傳感器,傳輸,屏幕像素切換的延遲都為0

假設(shè)我們?cè)诿繋_(kāi)始的時(shí)候(上一次垂直同步結(jié)束)采樣一次傳感器數(shù)據(jù),在垂直同步之前完成提交,那延遲就是16.67ms

如果當(dāng)前幀無(wú)法在16.67ms內(nèi)完成渲染,比如花了17ms,那么就會(huì)拖到下一幀進(jìn)行提交,屏幕上顯示的畫(huà)面就還是上一次的圖像,這時(shí)候的延遲就變成了16.67*2=33.33ms

這就對(duì)VR的渲染提出了非常高的要求:

FPS必須達(dá)到刷新率的要求,90Hz就是90Hz,80FPS是不行的,會(huì)被垂直同步拖累成45FPS

FPS必須保證穩(wěn)定,偶爾掉一兩幀在VR中的感覺(jué)非常明顯,可能某個(gè)物體的位置已經(jīng)差了幾十個(gè)像素了

以O(shè)culusRift(消費(fèi)版)為例,1080x1200x2的屏幕分辨率,90Hz的刷新率,再加上因?yàn)樽冃嗡枰腢pSampling,實(shí)際的渲染畫(huà)面就是3024x1680@90Hz,這性能壓力幾乎與4k@60Hz相當(dāng).所以,單純的提升刷新率和分辨率,目前來(lái)說(shuō)渲染能力還是跟不上.不過(guò)既然有了性能需求,硬件廠商才有前進(jìn)動(dòng)力,對(duì)整個(gè)行業(yè)生態(tài)來(lái)說(shuō),是件好事.

2、引擎層面的優(yōu)化

除了拼命優(yōu)化降低每幀畫(huà)面的渲染時(shí)間外,引擎層面還可以通過(guò)一些策略進(jìn)行優(yōu)化,關(guān)鍵的思路就是:能不能把采樣傳感器數(shù)據(jù)的時(shí)間點(diǎn)盡量延后,讓它與垂直同步的時(shí)間點(diǎn)盡量靠近?

這里我們?nèi)匀患僭O(shè)60Hz,每幀時(shí)間16.67ms(約17ms),忽略硬件延遲

如果在游戲邏輯過(guò)程中(1ms時(shí))采樣傳感器數(shù)據(jù),那延遲大約就是16ms

如果在渲染線程進(jìn)行繪制之前(5ms時(shí)),重新再采樣一下傳感器數(shù)據(jù),修正一下視口信息(不會(huì)對(duì)游戲邏輯產(chǎn)生影響),那延遲就縮短到了約12ms

做過(guò)渲染優(yōu)化的人都知道,提交D3DCommand后,需要等待GPU執(zhí)行完畢,這部分時(shí)間在整幀時(shí)間中的占比還是相當(dāng)高的.那有沒(méi)有辦法在渲染完成之后,提交到屏幕之前再次采樣一次傳感器數(shù)據(jù)呢?如果像下圖那樣的話,延遲可以縮短到3ms!!!

這就是Timewarp的主要思想,我們來(lái)看看它是怎么實(shí)現(xiàn)的

Timewarp

了解過(guò)延遲渲染的人應(yīng)該都知道,我們可以利用ZBuffer的深度數(shù)據(jù),逆向推導(dǎo)出屏幕上每個(gè)像素的世界坐標(biāo)

這就意味著,我們可以把所有像素變換到世界空間,再根據(jù)新的攝像機(jī)位置,重新計(jì)算每個(gè)像素的屏幕坐標(biāo),生成一幅新的圖像:

可以看到之前被遮擋區(qū)域的像素是缺失的,因?yàn)槲覀兊臄z像機(jī)位置變化了.那如果攝像機(jī)位置不變,僅僅是朝向變了呢?這樣就不存在像素可見(jiàn)性的變化了:

Timewarp正是利用了這個(gè)特性,在保證位置不變的情況下,把渲染完的畫(huà)面根據(jù)最新獲取的傳感器朝向信息計(jì)算出一幀新的畫(huà)面,再提交到顯示屏.由于角度變化非常小,所以邊緣不會(huì)出大面積的像素缺失情況.

Oculus的Demo中可以停止渲染新的畫(huà)面,完全由單幀圖像計(jì)算出各個(gè)朝向的新畫(huà)面:

也就是說(shuō),只要角度變化不是非常大(上圖為了演示效果偏轉(zhuǎn)的角度很大了),可以通過(guò)這項(xiàng)技術(shù)”憑空渲染”出下一幀的圖像,SONY的PSVR正是利用這一點(diǎn),把60FPS的畫(huà)面Reproject成了120FPS.

Timewarp只能處理頭部轉(zhuǎn)向,不能處理頭部移動(dòng)的情況,而且一旦錯(cuò)過(guò)了垂直同步的時(shí)機(jī),一樣需要等待下一次垂直同步才能顯示出來(lái).那能不能在每次垂直同步之前,強(qiáng)制進(jìn)行一次Timewarp呢?那就需要驅(qū)動(dòng)來(lái)開(kāi)個(gè)后門(mén)了…

3、驅(qū)動(dòng)層面的優(yōu)化

假設(shè)垂直同步時(shí),當(dāng)前幀還沒(méi)有渲染完畢,這時(shí)如果要進(jìn)行Timewarp的話,就需要驅(qū)動(dòng)提供一種高優(yōu)先級(jí)的異步調(diào)用,這就是異步Timewarp的由來(lái):Timewarp操作與場(chǎng)景渲染并行執(zhí)行,如果沒(méi)有新的渲染畫(huà)面,就繼續(xù)使用上一幀的畫(huà)面進(jìn)行Timewarp.

這可以在一定程度上補(bǔ)償FPS不達(dá)標(biāo)造成的延遲問(wèn)題,GearVR中正是應(yīng)用了這項(xiàng)技術(shù),保證了手機(jī)VR的體驗(yàn).

當(dāng)然,PC上使用項(xiàng)技術(shù)還是有一些限制:

必須是Fermi,Kepler,Maxwell(或更新)核心的GPU

GPU是以DrawCall為單位調(diào)度的,所以耗時(shí)太長(zhǎng)的DrawCall是插入不了Timewarp繪制操作的

需要最新的Oculus和NVIDIA驅(qū)動(dòng)支持

異步Timewarp并不是說(shuō)FPS低于標(biāo)準(zhǔn)還能流暢跑,這只是一種補(bǔ)救措施,所以優(yōu)化仍然要好好做-_-

驅(qū)動(dòng)方面還有一些其它的優(yōu)化空間,比如強(qiáng)制提交渲染隊(duì)列:

如果驅(qū)動(dòng)中緩存了3幀,那延遲優(yōu)化就白做了…

另外就是大家耳熟能詳?shù)腂ackBuffer(DoubleBufferRendering),其實(shí)也會(huì)增加一點(diǎn)延遲,不如省掉這一步,即FrontBufferRendering,或者叫DirectMode:

參考資料

WhatisMotion-To-PhotonLatency?

http://www.chioka.in/what-is-motion-to-photon-latency/

OptimizingVRGraphicswithLateLatching

/blog/optimizing-vr-graphics-with-late-latching/

VRDirect:HowNVIDIATechnologyisImprovingtheVRExperience

/xoyojank/article/details//talks/VR_Direct_GDC_2015.pptx

VirtualRealitywithAMDLiquidVR?Technology

/en-us/innovations/software-technologies/technologies-gaming/vr

LessonsfromIntegratingtheOculusRiftintoUnrealEngine4

/connect/sli