Oculus简述late latching技术，为Quest减少渲染延迟
late latching可为Quest开发带来帮助
（映维网 2019年12月20日）有数个因素会从根本上影响VR的舒适度，而延迟显然是其中之一。延迟越短，VR就越接近于现实，所以我们有必要不断改进它，直到有一天这个数字能够变为0。Oculus最近通过UE4.23 + Vulkan为Quest实现了后late latching（临末锁存）解决方案，并旨在帮助减少应用的渲染延迟。尽管你可以通过简单地选中Oculus Github UE4版本中的复选框来予以启用，但本文将为你介绍Oculus对这个解决方案的概述，设计/实现，它对Quest开发的重要，以及使用新版本的入门技巧。下面是映维网的具体整理：
1. 为什么Quest需要late latching呢？
在思考如何减少头显延迟时，late latching似乎是一个非常自然而显然的想法。有关late latching概念的综述请参阅这篇文章。
你可能会问：“发行的应用中为什么没有启用了late latching的内容呢？ 如果以前Rift不需要，为什么现在Quest需要呢？我们可以从两个角度回答：一个是硬件角度，另一个是软件角度。
首先，由于GPU架构的原因，在Quest启用late latching的效果要比Rift更为有效。与可以在渲染线程生成后立即开始处理GPU命令的PC显卡不同，Quest显卡（Adreno 540）是采用基于图块的架构，其需要在启动GPU之前采集整个帧的绘制调用信息。从本质上讲，CPU到GPU的等待时间更长，这意味着late latching会带来非常大的好处。
其次，Vulkan终于足够成熟，能够在移动硬件进行开发。Vulkan具有执行显式内存管理的能力，以及优化的CPU-GPU同步管理能力，这两者都使实现强大的late latching解决方案成为可能。
有关Vulkan for Mobile VR开发的信息请参阅这篇文章：研发实战：如何在Oculus Mobile VR平台进行Vulkan开发 。
2. late latching的设计与实现
对于实现late latching，我们是希望在GPU开始使用追踪相关的渲染数据（通常是存储视图矩阵的统一缓冲区）之前，安全地对其进行重新更新。
首先，我们需要在提交绘制调用后重新更新追踪相关的数据。对于GLES，这可能非常困难，因为驱动程序管理统一的缓冲内存，你可能必须依靠供应商特定的扩展来执行这项操作，所以对于游戏引擎集成而言可能不太理想。但对于Vulkan，它要简单得多，因为我们总是自己管理内存。在这种情况下，我们只需要视图统一缓冲区为HOST_VISIBLE和HOST_COHERENT，然后即可映射一次，保存pointer，并在任何时候轻松地予以修改。
第二，我们需要安全地这样做。我们必须保证在GPU同时读取数据时不会修改数据，否则，我们可能会遇到许多意外行为。根据游戏引擎的渲染提交行为，以及我们拥有多少控制权，我们可以使用以下两个选项来进行处理。
2.1 有保障的方法
如果我们将游戏引擎视为一个黑盒子，一种更新追踪相关渲染数据的方法是通过CPU-GPU同步。我们只需在渲染任何内容之前添加vkCmdWaitEvents即可抓住GPU，以防发生中间帧刷新。接下来，我们在帧的末尾重新更新视图统一缓冲区，然后直接调用vkSetEvent放开GPU。这涵盖了所有情况，包括GPU在帧中隐式启动或显式启动。
2.2 简单的方法
对于UE4移动渲染器，实际的情况要简单得多。通常，这里没有中间帧刷新，并且的仅使用单个vkQueue。GPU在vkQueueSubmit之前是不会处理由渲染线程生成的绘制调用，所以我们可以在vkQueueSubmit之前使用新获取的HMD姿态来重新更新视图统一缓冲区。
作为开源引擎，某些中间帧提交可能会在后面添加到UE4中。要检测这些错误，我们添加了一个用于检测中间帧提交的late latching终止系统。如果触发，系统将终止帧中的late latching，并警告“Late Latching终止”。请注意，如果应用程序出现包含所述警告的大量日志，则可能意味着你的本地修改与简单的late latching实现存在冲突，所以你可能需要添加vkCmdWaitEvents/vkSetEvent机制。
3. UE4实现细节
在上一节中，我们概述了late latching的设计方式，而实际的UE4实现中存在一些有趣的细节：
- “Late update”：UE4为VR提供了一个“Late Update（临末更新）”系统，这为引擎提供了在渲染线程开始时更新追踪相关渲染数据的最后机会。实际上，所述系统非常适合late latching。你可以将late latching视为“Late Late Update（最后的临末更新）”。
- 移动Vulkan统一缓冲区：UE4的移动vulkan统一缓冲区处理非常独特。与大多数引擎不同，它有多个统一缓冲区，而每个缓冲区都有自己的用途。对于所有绘制调用，UE4仅有一个单一的巨型统一缓冲区（8M）：“Packed Uniform Buffer System”。每个绘制调用将从巨大的统一缓冲区中分配，并将所有必要的统一缓冲区数据打包到其中。这种解决方案可以大大减少PSO量。然而，它为late latching带来了额外的复杂性，因为我们不能只更新一个单一的共享视图统一缓冲区，我们必须跟踪所有视图矩阵的位置，并在渲染线程的末尾逐一处理。这会增加late latching的开销，但幸运的是，对于我们测试的大多数应用而言，这并不明显，因为它的CPU开销最小（0.1ms-0.3ms）。
- 控制器late latching：从图形API的角度来看，头显锁存和控制器锁存之间没有重大的区别。但是，控制器可以具有相对复杂的transform hierarchy。例如，如果刀刃包含发光的宝石并且需要在整个过程中应用late latching，在控制器接收到新的姿态后，我们必须走过整个hierarchy。幸运的是，late-update系统可以分担大量的工作。
4. late latching的优势及如何着手利用
late latching可以节省多少延迟取决于应用程序的渲染线程工作量。有趣的是，渲染线程的计算方面成本越高，可以节省的延迟就越多，这是因为渲染线程的起点与late latching点之间的差异变得更大。
通常来说，较低的延迟应该能够提高VR舒适度，并且在视觉方面减少多种常见的图形伪影。
- 更少的时间扭曲黑色拖影：旋转延迟可以通过TimeWarp进行充分管理，但较低的预测延迟依然可以帮助减少黑色拖影。
- 更为空间稳定的近场对象：位置延迟会最大程度地影响近场对象，如果你正在看着近场对象而且头部进行平移运动，你可能会看到所述对象变得摇晃。减少延迟可以帮助改善这种情况。
- 更好的控制器体验：较短的预测延迟同样有助于控制器运动，这将减少用户挥动控制器时的过冲和下冲。
我们的late latching解决方案已经作为实验性功能纳入至1.41版本。要予以启用，你只需通过GitHub下载UE4.21版本并且在Project Settings中勾选“Late Latching”复选框即可。
记得勾选“Supprot Vulkan”。
5. 建议
应用的渲染延迟可以通过logcat进行读取，键入“adb logcat -s VrApi”后你会看到诸如“I/VrApi (26422): FPS=72,Prd=45ms,Tear=0,Early=73,Stale=0,VSnc=1,Lat=1,Fov=0 ….”这样的日志。“Prd”的指应用的最新渲染延迟。我们已经在UE4中增加了一个console variable：“r.ForceDisableLateLatching”。如果你动态地切换并观察Prd值，你可以看到late latching节省地毫秒数。
