VR渲染延迟优化方法

来源:互联网 发布:java多线程 的讲解 编辑:程序博客网 时间:2024/04/29 04:02

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, 实际的渲染画面就是3024x1680@90Hz, 这性能压力几乎与4k@60Hz相当. 所以, 单纯的提升刷新率和分辨率, 目前来说渲染能力还是跟不上. 不过既然有了性能需求, 硬件厂商才有前进动力, 对整个行业生态来说, 是件好事.

引擎层面的优化

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

这里我们仍然假设60Hz, 每帧时间16.67ms(约17ms), 忽略硬件延迟 
这里写图片描述
如果在游戏逻辑过程中(1ms时)采样传感器数据, 那延迟大约就是16ms 
这里写图片描述
如果在渲染线程进行绘制之前(5ms时), 重新再采样一下传感器数据, 修正一下视口信息(不会对游戏逻辑产生影响), 那延迟就缩短到了约12ms 
这里写图片描述
做过渲染优化的人都知道, 提交D3D Command后, 需要等待GPU执行完毕, 这部分时间在整帧时间中的占比还是相当高的. 那有没有办法在渲染完成之后, 提交到屏幕之前再次采样一次传感器数据呢? 如果像下图那样的话, 延迟可以缩短到3ms!!! 
这里写图片描述
这就是Timewarp的主要思想, 我们来看看它是怎么实现的

Timewarp

了解过延迟渲染的人应该都知道, 我们可以利用ZBuffer的深度数据, 逆向推导出屏幕上每个像素的世界坐标 
这里写图片描述
这就意味着, 我们可以把所有像素变换到世界空间, 再根据新的摄像机位置, 重新计算每个像素的屏幕坐标, 生成一幅新的图像: 
这里写图片描述
可以看到之前被遮挡区域的像素是缺失的, 因为我们的摄像机位置变化了. 那如果摄像机位置不变, 仅仅是朝向变了呢? 这样就不存在像素可见性的变化了: 
这里写图片描述
Timewarp正是利用了这个特性, 在保证位置不变的情况下, 把渲染完的画面根据最新获取的传感器朝向信息计算出一帧新的画面, 再提交到显示屏. 由于角度变化非常小, 所以边缘不会出大面积的像素缺失情况. 
这里写图片描述
Oculus的Demo中可以停止渲染新的画面, 完全由单帧图像计算出各个朝向的新画面: 
原始图像向左上看向右下看
也就是说, 只要角度变化不是非常大(上图为了演示效果偏转的角度很大了), 可以通过这项技术”凭空渲染”出下一帧的图像, SONY的PSVR正是利用这一点, 把60FPS的画面Reproject成了120FPS. 
Timewarp只能处理头部转向, 不能处理头部移动的情况, 而且一旦错过了垂直同步的时机, 一样需要等待下一次垂直同步才能显示出来. 那能不能在每次垂直同步之前, 强制进行一次Timewarp呢? 那就需要驱动来开个后门了…

驱动层面的优化

假设垂直同步时, 当前帧还没有渲染完毕, 这时如果要进行Timewarp的话, 就需要驱动提供一种高优先级的异步调用, 这就是异步Timewarp的由来: Timewarp操作与场景渲染并行执行, 如果没有新的渲染画面, 就继续使用上一帧的画面进行Timewarp. 
这里写图片描述
这可以在一定程度上补偿FPS不达标造成的延迟问题, GearVR中正是应用了这项技术, 保证了手机VR的体验. 
当然, PC上使用项技术还是有一些限制:

  • 必须是Fermi, Kepler, Maxwell(或更新)核心的GPU
  • GPU是以DrawCall为单位调度的, 所以耗时太长的DrawCall是插入不了Timewarp绘制操作的
  • 需要最新的Oculus和NVIDIA驱动支持

异步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渲染需要左右眼两幅不同的画面,现在的大部分引擎都是暴力的直接渲染两遍,这样做想想性能也很难达到75FPS(或90FPS)

以Oculus DK2为例,1920x1080@75FPS,加上Super Sampling就变成了(UE4默认135%)2592x1458@75FPS

如果是Oculus的消费者版本和HTC Vive,分辨率和刷新率更是提升到了2160x1200@90FPS, 推荐配置是GTX980惊恐

以140%的Super Sampling为标准的话,只是Color Buffer每秒的数据量就有2160x1200x1.4x1.4x90x4 byte ≈ 1.7GB

这还没算Post Processing里的N多张Render Target和Deferred Rendering的GBuffer、Light Buffer


性能永远是VR渲染的最具有挑战的部分,本着能省一点是一点的思路,VR的渲染优化我总结了这么一些:


虽然VR渲染需要左右两幅画面, 但是有很多效果是不需要画两次的:

  • Shadow Map
  • 部分的Reflection
  • Occlusion Query
  • 大多数Post Processing

API层面的优化, 有这么几个思路:

  • 如果实现了多线程的渲染,一般会有一个Command Buffer,直接分别以不同的View提交两次
  • 针对每个物体分别提交两次, 相比上面这个State切换开销会节省一些
  • 使用Geometry Shader直接把Mesh分成左右眼的,drawcall不会翻倍了。但是坑爹的GS性能不咋地
  • 使用Instancing一次drawcall绘制两个Viewport, 跟GS类似,但性能大约是GS的3倍
这只是减少一些API调用、State切换还有Vertex处理的消耗,那瓶颈最大的Pixel处理的消耗怎么减少呢?

Valve使用一个Stencil Mesh, 剔除了17%的像素


NVIDIA的GameWorks也提供了一种方法, 叫Multi-Resolution Shading,大概的思路就是边缘的像素经过变形后会损失一些,另外人眼对视线中心的像素更敏感,所以周围一圈可以降低分辨率来渲染。通过这种方式可以节省25%到50的像素

硬件方面,NVIDIA和AMD都推出了双GPU渲染的支持,即每块GPU渲染一只眼睛的画面。嗯,这一定是个阴谋,他们肯定在偷着乐:这下显卡不愁卖了


SONY的PS VR在PS4的机能下实现了120FPS。听起来不可思议,实际是60FPS通过reproject插值出中间帧,跟Killzone的Temporal Reprojection 和Oculus的Timewrap差不多原理


参考资料:

Fast Stereo Rendering for VR - Google Slides - Google Docs

'Advanced VR Rendering' by Alex Vlachos (Valve) - Steam

GameWorks VR Presentation - NVIDIA Developer

Asynchronous Timewarp Examined

原文链接:http://blog.csdn.net/xoyojank/article/details/50667507

0 0
原创粉丝点击