一些VR延遲優化方法

vr中的」延遲」, 特指」motion-to-photon latency」, 指的是從使用者運動開始到相應畫面顯示到螢幕上所花的時間.

這中間經過了大概這麼幾個步驟:

感測器採集運動輸入資料

採集到的資料進行過濾並通過線纜傳輸到主機

遊戲引擎根據獲取的輸入資料更新邏輯和渲染視口

提交到驅動並由驅動傳送到顯示卡進行渲染

把渲染的結果提交到螢幕, 畫素進行顏色的切換

使用者在螢幕上看到相應的畫面

當然, 實際上還有很多細節問題, 比如螢幕上的畫素並不是同一時間切換的, 可能面上面的那行先切換, 再一行行更新到最下面的, 在這裡就不糾結這些細節了.

這其中的每乙個步驟都會產生一定的延遲, 而目前公認的大眾能接受的延遲是20ms以下, 這基本上可以做為衡量乙個vr頭顯是不是合格的乙個標準. 雖然20ms是非常短的時間, 但通過努力還是可以達到的, 主要有這麼幾個思路:

大部分的手機vr產品在延遲上都是不合格的, 最明顯的表現就是轉頭時的畫面不連續/抖動/殘影等:

假設重新整理率為60hz, 並不是代表每幀就有16.67ms的延遲, 而是說螢幕影象每16.67ms才更新一次, 渲染選項中的」垂直同步」的概念就是**於此. 這就對我們提交渲染畫面的時機要求非常高, 如下圖:

為了方便計算, 這裡先假設感測器, 傳輸, 螢幕畫素切換的延遲都為0

這就對vr的渲染提出了非常高的要求:

以oculus rift(消費版)為例, 1080x1200x2的螢幕解析度, 90hz的重新整理率, 再加上因為變形所需要的upsampling, 實際的渲染畫面就是3024x1680@90hz, 這效能壓力幾乎與4k@60hz相當. 所以, 單純的提公升重新整理率和解析度, 目前來說渲染能力還是跟不上. 不過既然有了效能需求, 硬體廠商才有前進動力, 對整個行業生態來說, 是件好事.

除了拼命優化降低每幀畫面的渲染時間外, 引擎層面還可以通過一些策略進行優化, 關鍵的思路就是: 能不能把取樣感測器資料的時間點盡量延後, 讓它與垂直同步的時間點盡量靠近?

這裡我們仍然假設60hz, 每幀時間16.67ms(約17ms), 忽略硬體延遲

如果在遊戲邏輯過程中(1ms時)取樣感測器資料, 那延遲大約就是16ms

如果在渲染執行緒進行繪製之前(5ms時), 重新再取樣一下感測器資料, 修正一下視口資訊(不會對遊戲邏輯產生影響), 那延遲就縮短到了約12ms

做過渲染優化的人都知道, 提交d3d command後, 需要等待gpu執行完畢, 這部分時間在整幀時間中的佔比還是相當高的. 那有沒有辦法在渲染完成之後, 提交到螢幕之前再次取樣一次感測器資料呢? 如果像下圖那樣的話, 延遲可以縮短到3ms!!!

這就是timewarp的主要思想, 我們來看看它是怎麼實現的

了解過延遲渲染的人應該都知道, 我們可以利用zbuffer的深度資料, 逆向推導出螢幕上每個畫素的世界座標

這就意味著, 我們可以把所有畫素變換到世界空間, 再根據新的攝像機位置, 重新計算每個畫素的螢幕座標, 生成一幅新的影象:

可以看到之前被遮擋區域的畫素是缺失的, 因為我們的攝像機位置變化了. 那如果攝像機位置不變, 僅僅是朝向變了呢? 這樣就不存在畫素可見性的變化了:

timewarp正是利用了這個特性, 在保證位置不變的情況下, 把渲染完的畫面根據最新獲取的感測器朝向資訊計算出一幀新的畫面, 再提交到顯示屏. 由於角度變化非常小, 所以邊緣不會出大面積的畫素缺失情況.

oculus的demo中可以停止渲染新的畫面, 完全由單幀影象計算出各個朝向的新畫面:

也就是說, 只要角度變化不是非常大(上圖為了演示效果偏轉的角度很大了), 可以通過這項技術」憑空渲染」出下一幀的影象, sony的psvr正是利用這一點, 把60fps的畫面reproject成了120fps.

timewarp只能處理頭部轉向, 不能處理頭部移動的情況, 而且一旦錯過了垂直同步的時機, 一樣需要等待下一次垂直同步才能顯示出來. 那能不能在每次垂直同步之前, 強制進行一次timewarp呢? 那就需要驅動來開個後門了…

假設垂直同步時, 當前幀還沒有渲染完畢, 這時如果要進行timewarp的話, 就需要驅動提供一種高優先順序的非同步呼叫, 這就是非同步timewarp的由來: timewarp操作與場景渲染並行執行, 如果沒有新的渲染畫面, 就繼續使用上一幀的畫面進行timewarp.

這可以在一定程度上補償fps不達標造成的延遲問題, gearvr中正是應用了這項技術, 保證了手機vr的體驗.

當然, pc上使用項技術還是有一些限制:

非同步timewarp並不是說fps低於標準還能流暢跑, 這只是一種補救措施, 所以優化仍然要好好做-_-

驅動方面還有一些其它的優化空間, 比如強制提交渲染佇列:

如果驅動中快取了3幀, 那延遲優化就白做了…

另外就是大家耳熟能詳的back buffer(double buffer rendering), 其實也會增加一點延遲, 不如省掉這一步, 即front buffer rendering, 或者叫direct mode:

what is motion-to-photon latency?

optimizing vr graphics with late latching

vr direct: how nvidia technology is improving the vr experience

virtual reality with amd liquidvr™ technology

lessons from integrating the oculus rift into unreal engine 4

oculus rift - how does time warping work?

asynchronous timewarp examined

一些VR延遲優化方法

VR延遲優化

一些關於API層面的優化的VR渲染優化方法

ElasticSearch優化的一些方法

一些VR延遲優化方法

VR延遲優化

一些關於API層面的優化的VR渲染優化方法

ElasticSearch優化的一些方法

相關推薦