“VR 应用程序每帧渲染两张图像，一张用于左眼，一张用于右眼。”人们通常这样来解释 VR 渲染，虽然没有错，但可能过于简单化了。对于 Quest 开发人员来说，了解全貌是有益的，这样你就可以使你的应用程序性能更高、视觉效果更吸引人，并轻松排除故障和解决问题。
这篇博文将带你了解 VR 帧的生命周期，解释从帧生成到最终显示的端到端过程。这段旅程可以分为三个阶段：
- 从帧生成到提交: 应用程序如何呈现帧，包括应用程序 API 和帧 timing 模型
- 从帧提交给合成器: 帧数据如何在 app 和合成器之间共享
- 从合成到显示: Compositor 的责任以及最终图像如何显示在 HMD(头显示) 显示器上
第一阶段：从帧生成到提交
对于 Quest 应用程序，我们使用 VrApi / OpenXR 与 HMD 进行通信。具体到渲染部分，这些 API 负责以下工作：
- 姿态预测：与传统的 3D 应用不同，大多数 VR 概念的设计都是为了减少延迟。要为 VR 中的特定帧设置渲染 camera，仅知道当前的头显姿态并不足够，我们同时需要知道帧何时显示在 HMD 屏幕上，这称为
PredictedDisplayTime。然后，我们可以利用所述时间来预测头显姿态，并用预测的姿态对帧进行渲染，从而大大减少渲染误差。 - 帧同步：VR Runtime 负责帧同步。我们(Quest)的 SDK 提供了 API 来控制帧何时启动，并且不允许应用以高于所需帧速率的速度运行，而是通常以与显示器相同的帧速率运行。app 不需要（也不应该）插入手动等待或帧同步。
对于特定的应用程序，根据它是使用 VrApi 还是 OpenXR，行为可能会有所不同，因此我们将分别解决。
VrApi Application
下面是一个典型的多线程 VrApi 应用程序的框架：
- Start the Frame：主线程调用 vrapi_WaitFrame 来启动主线程帧，并调用 vrapi_BeginFrame 来启动渲染线程帧。
- Get the Poses：应用通常需要知道头显和控制器在模拟线程（主线程）中的姿态，以便正确执行游戏逻辑或物理计算。要获取所述信息，我们需要调用
vrapi_GetPredictedDisplayTime，并使用返回的时间调用vrapi_GetPredictedTracking2。 - Rendering：在渲染线程中，我们可以使用从主线程获得的头显/控制器姿态来完成渲染。但是，大多数应用（如 UE4）选择在渲染帧开始时再次调用
vrapi_GetPredictedDisplayTime / vrapi_GetPredictedTracking2。这是一个减少延迟的优化。我们正在预测头显在预测的显示时间中的姿态，我们越晚调用传感器采样 API，我们需要执行的预测就越少，从而能够获得更准确的预测。 - Submit Frame：在渲染线程完成所有调用提交之后，应用程序应该调用
vrapi_SubmitFrame2来告诉 VR 运行时应用已完成帧的 CPU 工作.它将向 VR 运行时提交有用的信息（注意：由于同步的性质，GPU 的工作可能依然在进行中，我们将在后面讨论）。然后，提交帧的 API 将执行以下操作：- Frame Synchronization：如果帧完成得太快，在这里阻塞以避免下一帧过早开始，保证应用不会以高于系统所需的 FPS 运行（例如，Quest 默认情况下是 72 FPS）。
- Check Texture Swap Chain Availability(检查 texture 交换链的可用性)：从 Swap Chain 阻塞下一个 eye texture 如果这个 texture 依然在运行时使用的话 . 阻塞通常由过时帧触发，因为运行时必须将旧帧再重用一帧。
- Advance Frame：增加帧的 index 并决定下一帧的预测显示时间，下一帧的
vrapi_GetPredictedDisplayTime调用将依赖于 vrapi_SubmitFrame2。
这就是大多数 VrApi 应用的工作方式。不过，有两条评论值得一提：
- 由于历史原因，
vrapi_BeginFrame / vrapi_WaitFrame是后来添加的，部分早期的应用程序只能访问vrapi_SubmitFrame2。 - 我们发布了PhaseSync作为 VrApi 的一个 opt-in 功能，它将帧同步移到了
vrapi_WaitFrame以更好地管理延迟。所以，帧行为更类似于 OpenXR 应用，我们将在下面讨论。
OpenXR Application
与 VrApi 应用相比，OpenXR 应用存在关键的区别：
- Start the Frame：使用 OpenXR 时，PhaseSync 始终处于启用状态，xrWaitFrame 将负责帧同步和延迟优化，以便 API 可以阻塞调用线程。另外，开发者不需要调用特殊的 API 来获得 predictedDisplayTime。这个值是从 xrWaitFrame 通过 XrFrameState:：predictedDisplayTime 返回。
- Get the Poses：要获取追踪姿态，开发者可以调用 xrLocateViews，它类似于 vrapi_GetPredictedTracking2。
- Rendering：需要注意的是，OpenXR 有专门的 API 来管理交换链；在将内容渲染到交换链之前，应调用 xrAcquireSwapchainImage/xrWaitSwapchainImage。如果合成器尚未释放交换链图像，xrWaitSwapchainImage 可以阻塞渲染线程。
- Submit Frame:xrEndFrame 负责帧提交，但与 vrapi_SubmitFrame2 不同，它不需要进行帧同步和交换链可用性检查，所以这个函数不会阻塞渲染线程。
一个典型的多线程 Open XR 应用程序的框架如下图所示：
总的来说，无论你是在开发 VrApi 应用还是 OpenXR 应用，有两个主要的阻塞源；一个来自帧同步，一个来自交换链可用性检查。如果你事先执行了 Systrace 抓取，你将看到一个熟悉的结果。当应用以满 FPS 运行时，这种 sleep 是可以预期的，因为除了优化延迟之外，它们（像 eglSwapBuffer 这样的传统 vsync 函数）同时阻塞应用程序以超出显示器允许的速度呈现。当应用程序无法达到目标 FPS 时，情况就会变得更为复杂。例如，由于新帧延迟，合成器可能仍在使用以前提交的图像。这导致“交换链可用性检查”阻塞变长，并且可能导致帧同步阻塞。这就是为什么当应用程序已经很慢的时候，应用程序仍然在阻塞上花费时间。出于这些原因，我们不建议使用 FPS 作为性能剖析指标，因为它通常不能准确反映应用工作负载。gpusystrace 和 Perfetto 是在 CPU 和 GPU 端测量应用性能的更好工具。
第二阶段：从帧提交到合成器
我们的 VR 运行时是围绕 Out of Process Composition（OOPC）这一概念设计。我们有一个独立的进程：VR Compositor。它在后台运行，同时从所有客户端收集帧提交信息，然后进行合成和显示。
VR 应用是从中收集帧信息的客户端之一。提交的帧数据将通过进程间通信(IPC)发送到 VR 合成器。我们不需要将 eye buffer 的副本发送到合成器进程，因为这意味着大量的数据。相反，eye buffer 的内存所有权从交换链分配开始就属于合成器进程。所以，只需要交换链句柄和交换索引。但是，我们确实需要保证数据的访问是安全的，这意味着合成器应该只在应用完成渲染后读取数据，并且应用程序不应该在合成器使用数据时修改数据。这是通过 FenceChecker 和 FrameRetirement 系统完成。
FenceChecker
Quest GPU（高通 Adreno 540/650）是 Tile-Based 架构，其只在提交所有调用后才开始工作（直到显式或隐式 flushing）。当应用程序调用SubmitFrame 时，通常 GPU 才刚刚开始渲染相应的 eye texture（因为大多数引擎在调用 SubmitFrame 之前都会显式 flush GPU）。如果这个时候合成器立即读取提交的图像，它将会接收未完成的数据，从而导致图形损坏和撕裂。
为了解决这个问题，我们在帧尾向 GPU 命令流（vrapi_SubmitFrame / xrEndFrame）发出一个 fence 对象，然后启动一个异步线程（FenceChecker）来等待。fence 是一个 GPU->CPU sync 原语，它可以在 GPU 处理到达 fence 时告诉 CPU。因为我们在帧尾插入了 fence，当 fence 返回时，我们就能知道 GPU 帧已经完成，然后我们可以通知合成器现在可以使用所述帧。
systrace 抓取的流程图：
提示：对于大多数应用程序，FenceChecker 标记的长度与应用程序 GPU 成本大致相同。
Frame Retirement
FenceChecker 有助于将眼睛纹理的所有权从应用程序转移到合成器，但这只是周期的一半。在帧完成显示后，合成器需要将数据的所有权交还给应用程序，以便它可以再次使用 eye texture，这称为“Frame Retirement”
VR 合成器设计用于处理延迟（暂停）帧，如果预期帧未按时交付，则重用帧并将其再次投影到显示器。因为我们不知道下一帧是否能在下一个合成周期准时到达(TW)，所以我们必须等到合成器拾取下一帧后才能释放当前帧。一旦合成器确认不再需要该帧，它就会将该帧标记为“retired”，以便客户端知道该帧已被合成器释放。
你可以通过 Systrace 查看,当 TimeWarp 读取新帧时，需要返回相应帧的客户端 FenceChecker，以确认 GPU 渲染完成。
第三阶段：从合成到显示
这时，帧（eye textures）已到达合成器，需要在 VR 显示屏显示。根据硬件的不同，这大致会发生涉及以下组件的一系列步骤：
- Layer Composition：负责混合不同的合成器层。层可以来自一个或多个客户端
- TimeWarp：我们用以减少头显旋转延迟的重投影技术
- Distortion Correction：VR 透镜造成畸变以增加感知视场。为了帮助用户看到一个非畸变的世界，反畸变非常必要。
- 其他后处理：存在其他后处理，如色差校正(CAC)。
从开发者的角度来看，以上大都是作为显示管道的一部分自动完成，并可以将它们视为黑盒。在所有这些艰苦的工作完成后，屏幕会在 PredictedDisplayTime 点亮，而用户会看到你的应用程序显示出来。
考虑到合成器工作的重要性（如果没有合成器，屏幕将被冻结），它在 GPU 上的更高优先级上下文中运行，并在需要执行时中断任何其他工作负载，例如渲染。你可以在 GPU systrace 上看到它对 Preempt blocks 的影响。对于 Quest1 和 Quest2，它的每帧工作分成两部分以优化延迟，通常每帧抢占两次，因为它每 7 毫秒运行一次。
总结
我们希望这篇概述有助于 Quest 开发者进一步理解系统，并帮助你构建更好的 VR 应用程序。从应用渲染开始到显示结束，我们介绍了一个典型的 VR 帧生命周期。我们解释了客户端应用和合成器服务器之间的数据流。如果你有问题或反馈，请通过 Oculus 开发者论坛告诉我们。