从家用游戏机到PC虚拟现实游戏： 《不语者》给我们的启示

1. 简介

《不语者》(Unspoken* ) * 是一款由 Insomniac Games* 公司开发的第一人称魔咒虚拟现实游戏，采用了 Oculus Touch* 控制器。。 Insomniac Games 是一家经验丰富的家用游戏机开发公司，他们的内部引擎经过扩展后可以支持虚拟现实技术开发。 从帧速率为 30 fps 的家用游戏机，到高端虚拟现实设备上的 90 fps，帧速率的大幅提升要求更好的性能感知设计和引擎性能改善，以实现最大程度地利用系统资源。 本文介绍了如何检测系统级别的引擎中所存在的技术瓶颈，其背后的原因，以及如何消除这些瓶颈以提升性能。

2. 引擎架构

在详细讨论之前，我们首先来介绍一下 Insomniac Games 引擎架构， 该引擎主要由以下部分构成：

i) 主线程 (MT)
- MT 负责对游戏中的物体进行模拟，以及准备下一帧的渲染工作缓冲。 前者包括蒙皮、物理和视觉效果，后者包括视锥和遮挡剔除。

ii) 渲染提交线程 (RS)
- RS 负责处理渲染工作缓冲，并将其转化为渲染命令 (DirectX* 11)。 它可以更新各种资源，并使用即时语境（immediate context），而非延迟语境（deferred context）。 当 RS 没有向 GPU 提交工作时，可以用作工作线程。

iii) 工作线程
- 我们使用 4 个高优先级工作线程和 4 个低优先级工作线程，可以运行蒙皮、物理和视觉效果等。

MT 提前运行一个帧，也就是说，当它在处理 N+1 帧时，RS 将 N 帧的工作提交至 GPU。 虽然这会导致一帧的输入延迟，但是系统本身的并行性和松散耦合特性有助于提升性能。

2.1 家用游戏机与 PC

在家用游戏机上，GPU 几乎与 RS 同步运行。 MT 和 RS 之间保持紧密同步，当 GPU 开始执行后处理工作时，RS 立即唤醒 MT。 这有助于 MT 率先提交蒙皮工作，进而更新顶点缓冲区，以确保帧 RS 随后提交。而且，GPU 能够持续提供处理资源（有可能出现资源不足的风险），同时有效降低输入延迟。

在 PC 上，DirectX Present 发挥着遏制的作用（取决于具体的参数和最大帧延迟），可防止 CPU 过度领先 GPU 现象的发生。 在没有介入性 GPU 查询（用于停止 RS）的情况下，便无法及时唤醒 MT。因此，引擎中的 PC 路径在 Present 返回结果后唤醒 MT。

3. 虚拟现实中的系统级性能分析

在 Oculus Connect* 3 发布后，我们观察到一个现象，帧开始时，GPU 队列中出现气泡（闲置时间）。 在虚拟现实游戏中，GPU 的目标是在　10 毫秒内达到 90 fps，1 毫秒左右的 GPU 闲置时间意味着 10% 的资源未被利用！ 下图中的 GPUView* 和 RAD 遥测* 时间线反映了这个问题：

之前： 帧开始时的 GPU 气泡（大约 1 毫秒）。 对于 GTX 980* ，这些帧使用 7 毫秒左右的时间进行渲染，包含游戏中的一个轻型工作负载。

之前： RAD 遥测中基于任务的时间线视图显示了这个问题。
3.1 了解引擎依赖性

气泡由 MT 和 RS 之间的几个依赖性引起。

i)
在 mirror-Present （在非 HMD 显示器上显示游戏）调用 Oculus* API ovr_submitFrame之前，MT 等待 RS 唤醒虚拟现实中的 post-Present。ovr_submitFrame 可限制（阻止）应用提交比 HMD 刷新率（在 Rift* 上为 90Hz）更快的帧。
在英特尔® 酷睿™ i7 6700K 上，CPU 帧时（RS 提交时间）约为 5 至 6 毫秒，这意味着 ovr_submitFrame 受阻了大约 5 毫秒，在这段时间内，引擎线程几乎完全闲置。

ii) RS 等待 MT 提交并同步蒙皮工作
如果 MT 不先运行，RS 将会等待生成蒙皮定点缓冲数据，然后才能提交图形缓冲区通道中的蒙皮对象。

iii) MT 等待 RS 复制下采样深度数据（每只眼睛），以便执行遮挡剔除查询
引擎使用室内遮挡剔除系统，在这个系统内，MT 等待 RS 对临时缓冲进行映射、复制和取消映射等操作，该缓冲保存着每只眼睛的下采样深度数据。 使用的数据有两帧：如果 MT 在 N 帧上工作，RS 复制 N-2 帧的深度数据后，MT 会对遮挡对象执行重新投影、填补孔洞以及剔除操作。

在低端的虚拟现实设备（如英特尔® 酷睿™ i5 4500 + GTX 970*）上，GPU 处理每帧工作负载的平均时间为 9 到 10 毫秒，1 毫米的气泡使它超出了 10 毫秒的 GPU 预算，此时必须开始运行异步空间扭曲* (Asynchronous Space Warp，ASW)，将游戏速度提升至 45Hz。 总体而言，最终用户对于虚拟现实的体验具有一定的主观性。对于观察力较为敏锐的玩家来说，当他们在快速移动手臂或 HMD 时，能够察觉 ASW 的延迟。

3.2 消除不必要的引擎依赖性

我们对引擎进行重构，确保 RS 能够唤醒 MT，并调用 ovr_submitFrame 和 mirror-Present。 这有助于为 MT 提供充足的时间来处理蒙皮和模拟工作，之后，它会等待 RS 重新读取前一个帧的深度缓存（详见第 3.3 节）。 我们添加了一个开关，支持在两个模式之间动态切换，以验证是否得到改进。在低端设备上运行繁重的帧工作负载时，此举能有效避免 ASW 出现频繁延迟的现象。

下图为消除了依赖性 (i) 和 (ii) 后的 GPUView 和 RAD 遥测时间表：

之后： MT 在 RS 受阻之前已经启动，减少了开始时的 GPU 气泡。

之后： 开始时的气泡减少了，等待重新读取深度缓冲的时间更为明显。

帧开始时，GPU 队列中的气泡有所减少，但是可以看出，遮挡回读系统（在 N 帧上工作的主线程）正在渲染线程（向 N-1 帧提交工作）上等待处理分期（staging）资源（来自 N-2 帧的深度缓冲）的 CPU 副本。 右眼的深度缓冲流程和左眼一致。

3.3 处理遮挡回读系统

虽然左右眼睛的遮挡剔除在很多地方都是相同的，但是我们不希望引擎过多地偏离虚拟现实。 更为重要的是，MT 根本算不上一个瓶颈。 游戏仍旧受 GPU 的限制，消除 GPU 气泡有助于满足 10 毫秒的帧预算限制。

RS 之所以…查看全文
了解更多相关内容，请关注CSDN英特尔开发专区！

Intel技术双周刊已全面开启：订阅请点击这里。