一张VR图像帧的完整生命周期：从帧生成到帧显示

查看引用/信息源请点击：Oculus

从帧生成到最终显示的端到端过程

（映维网 2021年05月25日 星期二）“VR应用每帧渲染两张图像，左眼一张，右眼一张。”在解释VR渲染时你经常会听到这样的答案。尽管没错，但可能过于简单。对于Quest开发者，理解完整的情况十分有益，这可以帮助你提升应用的性能表现和视觉吸引力，并且可以轻松地定位和解决问题。

日前，Oculus开发者官网通过博文分享了一张VR帧的完整生命周期，解释了从帧生成到最终显示的端到端过程。下面是映维网的具体整理：

从帧生成到最终显示的这段旅程可分为三个阶段：

1. 从帧生成到提交：应用程序如何渲染帧，包括应用API和帧计时模型。
2. 从帧提交到合成器：如何在应用和合成器之间共享帧数据。
3. 从合成到显示：合成器的责任，以及头显如何显示最终图像。

第一阶段：从帧生成到提交

对于Quest应用，我们使用VrApi/OpenXR与头显进行通信。具体到渲染，相关API负责以下工作：

姿态预测：与传统的3D应用不同，大多数VR概念的设计都是为了减少延迟。要为VR中的特定帧设置渲染camera，仅知道当前的头显姿态并不足够，我们同时需要知道帧何时应显示在头显屏幕，这称为PredictedDisplayTime。然后，我们可以利用所述时间来预测头显姿态，并用预测的姿态对帧进行渲染，从而大大减少渲染误差。

帧同步：VR运行时负责帧同步。我们的SDK提供了API来控制帧何时启动，并且不允许应用以高于所需帧速率的速度运行，而是通常以与显示器相同的帧速率运行。应用不需要（不应该）插入手动等待或帧同步。

1. VrApi应用

以下是常见多线程VrApi应用的示例：

启动帧：主线程调用vrapi\u WaitFrame来启动主线程帧，并调用vrapi\BeginFrame来启动渲染线程帧。

获取姿态：应用通常需要知道头显和控制器在模拟线程（主线程）中的姿态，以便正确执行游戏逻辑或物理计算。要获取所述信息，我们需要调用vrapi_GetPredictedDisplayTime，并使用返回的时间调用vrapi_GetPredictedTracking2。

渲染：在渲染线程中，我们可以使用从主线程获得的头显/控制器姿态来完成渲染。但是，大多数应用（如UE4）选择在渲染帧开始时再次调用vrapi_GetPredictedDisplayTime / vrapi_GetPredictedTracking2。这是一个延迟减少优化。我们正在预测头显在预测的显示时间中的姿态，我们越晚调用传感器采样API，我们需要执行的预测就越少，从而能够获得更准确的预测。

提交帧：在渲染线程完成所有调用提交之后，应用程序应该调用vrapi_SubmitFrame2来告诉VR运行时：应用已完成帧的CPU工作。它将向VR运行时提交有用的信息（注意：由于同步的性质，GPU的工作可能依然在进行中，我们将在后面讨论）。然后，提交帧API将执行以下操作：

1. Frame Synchronization：如果帧完成得太快，在这里阻塞以避免下一帧过早开始，保证应用不会以高于系统所需的FPS运行（例如，Quest默认情况下是72 FPS）。
2. Check Texture Swap Chain Availability：如果运行时依然在使用，则从交换链阻塞下一个眼睛纹理。阻塞通常由过时帧触发，因为运行时必须将旧帧再重用一帧。
3. Advance Frame：增加帧索引并决定下一帧的预测显示时间，下一帧的vrapi_GetPredictedDisplayTime调用将依赖于vrapi_SubmitFrame2。

这就是大多数VrApi应用的工作方式。不过，有两条评论值得一提：

1. 由于历史原因，vrapi_BeginFrame / vrapi_WaitFrame是后来添加的，部分早期的应用程序只能访问vrapi_SubmitFrame2。
2. 我们发布了PhaseSync作为VrApi的一个opt-in功能，它将帧同步移到了vrapi_WaitFrame以更好地管理延迟。所以，帧行为更类似于OpenXR应用，我们将在下面讨论。

2. OpenXR应用

与VrApi应用相比，OpenXR应用存在关键的区别：

启动帧：使用OpenXR时，PhaseSync始终处于启用状态，xrWaitFrame将负责帧同步和延迟优化，以便API可以阻塞调用线程。另外，开发者不需要调用特殊的API来获得predictedDisplayTime。这个值是从xrWaitFrame通过XrFrameState:：predictedDisplayTime返回。

获取姿态：要获取追踪姿态，开发者可以调用xrLocateViews，它类似于vrapi_GetPredictedTracking2。

渲染：需要注意的是，OpenXR有专门的API来管理交换链；在将内容渲染到交换链之前，应调用xrAcquireSwapchainImage/xrWaitSwapchainImage。如果合成器尚未释放交换链图像，xrWaitSwapchainImage可以阻塞渲染线程。

提交帧:xrEndFrame负责帧提交，但与vrapi_SubmitFrame2不同，它不需要进行帧同步和交换链可用性检查，所以这个函数不会阻塞渲染线程。

以下是常见多线程OpenXR应用的示例：

总的来说，无论你是在开发VrApi应用还是OpenXR应用，有两个主要的阻塞源；一个来自帧同步，一个来自交换链可用性检查。如果你事先执行了Systrace抓取，你将看到一个熟悉的结果。当应用以全FPS运行时，这种sleep是可以预期的，因为除了优化延迟之外，它们（像eglSwapBuffer这样的传统vsync函数）同时阻塞应用程序以超出显示器允许的速度呈现。当应用程序无法达到目标FPS时，情况就会变得更为复杂。例如，由于新帧延迟，合成器可能仍在使用以前提交的图像。这导致“交换链可用性检查”阻塞变长，并且可能导致帧同步阻塞。这就是为什么当应用程序已经很慢的时候，应用程序仍然在阻塞上花费时间。出于这些原因，我们不建议使用FPS作为性能剖析指标，因为它通常不能准确反映应用工作负载。gpusystrace和Perfetto是在CPU和GPU端测量应用性能的更好工具。

第二阶段：从帧提交到合成器

我们的VR运行时是围绕Out of Process Composition（OOPC）这一概念设计。我们有一个独立的进程：VR Compositor。它在后台运行，同时从所有客户端收集帧提交信息，然后进行合成和显示。

VR应用是从中收集帧信息的客户端之一。提交的帧数据将通过进程间通信发送到VR合成器。我们不需要将眼睛缓冲区的副本发送到合成器进程，因为这意味着大量的数据。相反，眼睛缓冲区的内存所有权从交换链分配开始就属于合成器进程。所以，只需要交换链句柄和交换索引。但是，我们确实需要保证数据的访问是安全的，这意味着合成器应该只在应用完成渲染后读取数据，并且应用程序不应该在合成器使用数据时修改数据。这是通过FenceChecker和FrameRetirement系统完成。

1. FenceChecker

Quest GPU（高通Adreno 540/650）是Tile-Based架构，其只在提交所有调用后才开始工作（直到显式或隐式刷新）。当应用程序调用SubmitFrame时，通常GPU才刚刚开始渲染相应的眼睛纹理（因为大多数引擎在调用SubmitFrame之前都会显式刷新GPU）。如果这个时候合成器立即读取提交的图像，它将会接收未完成的数据，从而导致图形损坏和撕裂伪影。

为了解决这个问题，我们在帧尾向GPU命令流（vrapi\u SubmitFrame/xrEndFrame）发出一个fence对象，然后启动一个异步线程（FenceChecker）来等待。fence是一个GPU->CPU sync原语，它可以在GPU处理到达fence时告诉CPU。因为我们在帧尾插入了fence，当fence返回时，我们就能知道GPU帧已经完成，然后我们可以通知合成器现在可以使用所述帧。

Ssystrace抓取的序列：

建议，对于大多数应用程序，FenceChecker标记长度应大概等同于应用GPU成本。

2. Frame Retirement

FenceChecker有助于将眼睛纹理的所有权从应用程序转移到合成器，但这只是周期的一半。在帧完成显示后，合成器需要将数据的所有权交还给应用程序，以便它可以再次使用眼睛纹理，这称为“Frame Retirement”

VR合成器设计用于处理延迟（暂停）帧，如果预期帧未按时交付，则重用帧并将其再次投影到显示器。因为我们不知道下一帧是否能在下一个合成周期准时到达，所以我们必须等到合成器拾取下一帧后才能释放当前帧。一旦合成器确认不再需要该帧，它就会将该帧标记为“retired”，以便客户端知道该帧已被合成器释放。

你可以通过Systrace查看。当TimeWarp读取新帧时，需要返回相应帧的客户端FenceChecker，以确认GPU渲染完成。

第三阶段：从合成到显示

这时，帧（眼睛纹理）已到达合成器，需要在VR显示屏显示。根据硬件的不同，这大致会发生涉及以下组件的一系列步骤：

1. Layer Composition：负责混合不同的合成器层。层可以来自一个或多个客户端
2. TimeWarp：我们用以减少头显旋转延迟的重投影技术
3. Distortion Correction：VR透镜造成畸变以增加感知视场。为了帮助用户看到一个非畸变的世界，反畸变非常必要。
4. 其他后处理：存在其他后处理，如色差校正。

从开发者的角度来看，以上大都是作为显示管道的一部分自动完成，并可以将它们视为黑盒。在所有这些艰苦的工作完成后，屏幕会在PredictedDisplayTime点亮，而用户会看到你的应用程序显示出来。

考虑到合成器工作的重要性，它将在GPU以更高优先级运行，并在需要执行时中断任何其他工作负载，例如渲染。对于Quest1和Quest2，它的每帧工作分成两部分以优化延迟，通常每帧抢占两次，因为它每7毫秒运行一次。

总结

我们希望这篇概述有助于Quest开发者进一步理解系统，并帮助你构建更好的VR应用程序。从应用渲染开始到显示结束，我们介绍了一个典型的VR帧生命周期。我们解释了客户端应用和合成器服务器之间的数据流。如果你有问题或反馈，请通过Oculus开发者论坛告诉我们。