“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 開發者論壇告訴我們，
原文鏈接:https://developer.oculus.com/blog/a-vr-frames-life/
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/538579.html
標籤：其他