華為開發者大會2022（HDC）上，HMS Core手語數字人以全新形象亮相，併在直播中完成了長達3個多小時的實時手語翻譯，向線上線下超過一千萬的觀眾提供了專業、實時、準確的手語翻譯服務，為聽障人士提供了無障礙參會體驗。面對專業性強且辭彙量大的科技大會，HMS Core手語數字人是如何準確且流暢地打 ...

“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 毫秒運行一次。