一张VR图像帧的生命周期
“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 开发者论坛告诉我们。