卡马克揭开VR延迟背后的真相

原文：http://oculusrift-blog.com/john-carmacks-message-of-latency/682/

延迟是OculusVR所面对的最大挑战之一， 它不仅会分散玩家体验游戏时的注意力， 还会导致晕动症， 所以找出它背后的原因并消除它是非常重要的。

整个系统保持在50ms已经很快了， 但是还是可以感觉到延迟
20ms是可接受的最大延迟
传感器数据的推导预测可以缓解部分的系统延迟。但即使有一个非常复杂的人类头部运动模型， 也不能很好地处理开始运动和运动突变时的情况
滤波和传输是固定延迟， 但是离散的传感器数据包也会带来一个可变的延迟， 因为渲染的帧率与传感器的帧率是不一致的
早期的LCD在运动时有拖影， 尽管现在的工艺已经进步了很多， LCD的像素从一个值转变到另一个值大约仍要10ms, 专为3D游戏优化过的可以降低到一半以下
OLED的像素切换时间在1ms以下， 激光显示甚至与CRT一样快
有一个不易察觉的延迟， 多数显示器显示一幅图像时是逐渐出现的， 就像从计算机中扫描出来一样。 这就导致了60Hz刷新率的屏幕底部比顶部晚了16ms
这对于固定的显示器不是什么问题， 但是对于头戴式的显示器，它会引起画面左右割裂或者转头时的晃动。 这是因为原图像是即时生成的， 但不同部分却不是同一时间显示的。 这个现象在LCD头戴显示器上会因切换时间的问题被忽视， 但是在OLED头戴显示器上非常明显
有一个非常有吸引力的立体渲染方向， 就是双眼的画面各由一个GPU渲染， 这样可以带来最好的性能和最小的延迟， 只是需要应用程序管理好两个独立的渲染上下文
阻止GPU缓存的负面影响是会降低吞吐量， 造成高负载时的帧率下降
多数的模拟并不直接依赖用户的输入，可能在一帧的延迟中并不明显。如果输入数据是在使用到时再采样，就会比在帧开始时保存下来延迟要低
延迟帧调度（late frame scheduling）通常需要等待，浪费了一些性能。 如果你的帧率依赖video retrace而不是固定的时间片， 那么从显示驱动中获取当前的扫描输出位置会有帮助
另一个降低延迟的方法是允许渲染层基于最新的采样数据修改游戏层传过来的参数（VIEW BYPASS）。简单地说， 可以计算出本次用户输入与上次采样的差值，用于修改游戏层提交给渲染层的视图矩阵
差值处理是最小程度的侵入， 但也有一些情况是用户输入不能影响渲染的，如玩家死亡时的过场动画。或许VR游戏从设计上就应该避免在头戴显示器中出现不能响应的情况，但是依照传统游戏的惯例这种设计还是有很多的
如果你十分了解渲染一帧所花的时间，那么一些额外的延迟可以通过整个渲染任务的延迟帧调度来节省下来，但这对于频繁变化的帧渲染时间并不是一件容易的事。然而一个后期处理任务（TIME WARPING）可以降低意料之中的一些时间， 这样就可以更加容易地进行延迟调度
从你的角度尽可能使用最好的信息绘制了一帧后（已经应用了view bypass），不要急着直接显示出来， 开发者还可以再次获取最新的用户输入， 生成一个更新过的视图矩阵， 把渲染的画变换到更新过参数的位置上。 使用这个变换， 显示到屏幕上的画面就反映了最新的输入
view bypass和time wraping是互补的技术， 它们既可以独立使用也可以一起使用。time warping可以变换一个源图像的任意时间或位置到另一个， 一些视差和屏幕边缘的瑕疵又可以通过view bypass来弥补
需要模拟状态变更的动作， 如切换开关或武器开火， 仍然需要大约32-48ms的延迟通过整个管线， 显示出对应的画面信息时的延迟并不会低于bypass优化过的16-32ms。而最重要的头部朝向反馈却可以在60Hz的刷新率下延迟控制在2-18ms。结合低延迟的传感器和显示屏， 甚至可以做到不可察觉。连续的time warping让延迟低于3ms成为了可能，为人机交互打开了一片未曾探索过的新天地
传统的计算机交互并没有VR的延迟要求这么高， 但是敏感的人却可以说出20ms级别的鼠标反应差异， 所以这项技术对于非VR的应用也是值得推广的
一个有趣的应用就是云游戏， 客户端发送操作信息给远程服务器， 并返回游戏的视频流。这为玩家提供了极大便利，但网络和压缩的延迟使得动作向的游戏体验比较差。view bypass和time warping都可以在服务器上应用，能够抵消相当大一部分网络延迟。再进一步，time wraping如果可以在客户端本地运行，理论上可以降低到与本地应用程序相同的水平，不过把time wraping限制在30或40ms比较好，避免与源图像的距离差异过大。