虚拟现实头盔的刷新率和延迟有什么关系？

移动新媒体 • 7年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

提到虚拟现实头盔带来的沉浸式体验时，刷新率、延迟是我们经常提到的两个名词。那么，刷新率和延迟之间有什么关系呢?不妨看看知乎带来的解答。

提升刷新率的确对延迟优化有帮助，但延迟不仅仅与刷新率有关系。

VR中的“延迟”，特指“Motion-To-Photon Latency”，指的是从用户运动开始到相应画面显示到屏幕上所花的时间。

　　这中间经过了大概这么几个步骤：

1、传感器采集运动输入数据

2、采集到的数据进行过滤并通过线缆传输到主机

3、游戏引擎根据获取的输入数据更新逻辑和渲染视口

4、提交到驱动并由驱动发送到显卡进行渲染

5、把渲染的结果提交到屏幕，像素进行颜色的切换

6、用户在屏幕上看到相应的画面

当然，实际上还有很多细节问题，比如屏幕上的像素并不是同一时间切换的，可能面上面的那行先切换，再一行行更新到最下面的，在这里就不纠结这些细节了。

这其中的每一个步骤都会产生一定的延迟，而目前公认的大众能接受的延迟是20ms以下，这基本上可以做为衡量一个VR头显是不是合格的一个标准。虽然20ms是非常短的时间，但通过努力还是可以达到的，主要有这么几个思路：

硬件层面的优化

提升传感器的采样频率，减少刷新率与传感器频率的同步等待时间消耗;

提升传感器的精度，减少对采样数据进行稳定性过滤产生的延迟;

采用有线传输也有一部分原因是出于延迟的考虑;

屏幕使用OLED替代LCD，减少像素颜色切换的时间;

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

大部分的手机VR产品在延迟上都是不合格的，最明显的表现就是转头时的画面不连续/抖动/残影等：

市面上的手机采用OLED屏的还是少数，比如iPhone配个VR壳子那延迟就很感人;

如果依赖手机的陀螺仪进行转向模拟，其精度和频率远远达不到要求;

手机屏幕目前都是60Hz的刷新率，在延迟上本身就受限。

刷新率的提升

假设刷新率为60Hz，并不是代表每帧就有16.67ms的延迟，而是说屏幕图像每16.67ms才更新一次，渲染选项中的“垂直同步”的概念就是来源于此。这就对我们提交渲染画面的时机要求非常高，如下图：

　　为了方便计算，这里先假设传感器，传输，屏幕像素切换的延迟都为0

假设我们在每帧开始的时候(上一次垂直同步结束)采样一次传感器数据，在垂直同步之前完成提交，那延迟就是16.67ms;

如果当前帧无法在16。67ms内完成渲染，比如花了17ms，那么就会拖到下一帧进行提交，屏幕上显示的画面就还是上一次的图像，这时候的延迟就变成了16.67*2=33.33ms。

这就对VR的渲染提出了非常高的要求：

FPS必须达到刷新率的要求，90Hz就是90Hz，80FPS是不行的，会被垂直同步拖累成45FPS;

FPS必须保证稳定，偶尔掉一两帧在VR中的感觉非常明显，可能某个物体的位置已经差了几十个像素了。

以Oculus Rift(消费版)为例，1080x1200x2的屏幕分辨率，90Hz的刷新率，再加上因为变形所需要的UpSampling，实际的渲染画面就是3024×1680@90Hz，这性能压力几乎与4k@60Hz相当。所以，单纯的提升刷新率和分辨率，目前来说渲染能力还是跟不上。不过既然有了性能需求，硬件厂商才有前进动力，对整个行业生态来说，是件好事。

引擎层面的优化

除了拼命优化降低每帧画面的渲染时间外，引擎层面还可以通过一些策略进行优化，关键的思路就是: 能不能把采样传感器数据的时间点尽量延后，让它与垂直同步的时间点尽量靠近?

这里我们仍然假设60Hz，每帧时间16.67ms(约17ms)，忽略硬件延迟

　　如果在游戏逻辑过程中(1ms时)采样传感器数据，那延迟大约就是16ms

　　如果在渲染线程进行绘制之前(5ms时)，重新再采样一下传感器数据，修正一下视口信息(不会对游戏逻辑产生影响)，那延迟就缩短到了约12ms

　　做过渲染优化的人都知道，提交D3D Command后，需要等待GPU执行完毕，这部分时间在整帧时间中的占比还是相当高的。那有没有办法在渲染完成之后，提交到屏幕之前再次采样一次传感器数据呢? 如果像下图那样的话，延迟可以缩短到3ms!!!

　　这就是Timewarp的主要思想，我们来看看它是怎么实现的

Timewarp

了解过延迟渲染的人应该都知道，我们可以利用ZBuffer的深度数据，逆向推导出屏幕上每个像素的世界坐标