一張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 開發者論壇告訴我們。
浙公網安備 33010602011771號