檢視引用/資訊源請點選：映維網
透過RenderDoc最佳化Oculus Quest應用
（
映維網 2021年11月29日
）RenderDoc是一個支援Android的開源偵錯程式，可幫助你窺視應用渲染機制幕後情況。對於商用遊戲引擎，實際的渲染程式碼要麼是隱藏，要麼難以通過於各種內建子系統來解密，所以如果能夠看到引擎是如何確定場景在單幀中的渲染方式，何樂而不為呢？
當你透過RenderDoc捕獲一幀時，它會按照幀的發出順序記錄所有圖形API命令和資源，然後再播放它們。RenderDoc同時可以幫助你大致知曉GPU執行繪製需要多少時間和繪製邏輯組。
關於RenderDoc的另一個關鍵要點是，它完全免費，並且開源。具體請訪問官方的RenderDoc下載頁面。
延伸閱讀
：研發實戰一：如何透過RenderDoc最佳化Oculus Quest應用
延伸閱讀
：研發實戰二：如何透過RenderDoc最佳化Oculus Quest應用
延伸閱讀
：研發實戰三：如何透過RenderDoc最佳化Oculus Quest應用
延伸閱讀
：研發實戰四：如何透過RenderDoc最佳化Oculus Quest應用
映維網早前已經分享過一系列透過RenderDoc最佳化Oculus Quest應用的博文。現在，Meta開發者團隊又介紹了與之相關的主題技巧，下面是映維網的具體整理：
RenderDoc for Oculus是熱門圖形偵錯程式RenderDoc的定製分支。這個特定於Quest的工具提供了對底層GPU剖析資料的訪問，特別是來自Tile渲染器的資訊。我們正繼續改進工具，並增加了一系列德新功能，如Tile Browser和Oculus Performance Counters。深度剖析功能和各種圖形除錯功能令RenderDoc for Oculus成為了解決效能難題的一個重要工具。在這篇博文中，我們將回顧如何有效地利用RenderDoc for Oculus，以及你應該避免的陷阱。
1. 開始
RenderDoc for Oculus這個圖形偵錯程式允許你快速輕鬆地捕獲單幀，並詳細檢查任何應用。如果是剛剛接觸，你可以參閱下面的博文：
延伸閱讀
：研發實戰一：如何透過RenderDoc最佳化Oculus Quest應用
延伸閱讀
：研發實戰二：如何透過RenderDoc最佳化Oculus Quest應用
延伸閱讀
：研發實戰三：如何透過RenderDoc最佳化Oculus Quest應用
延伸閱讀
：研發實戰四：如何透過RenderDoc最佳化Oculus Quest應用
對於已經十分熟悉RenderDoc For Oculus的使用者，我們現在將深入探討如何充分利用這個工具。
2. 計時器按鈕行為
計時器按鈕是RenderDoc最熱門的功能之一，因為它簡單易用。從v23。2開始，我們改動計時器按鈕行為以進行渲染通道測量，而不是繪製呼叫測量。這一變化的原因是效能查詢：因為基於Tile的GPU架構，RenderDoc用於測量每次繪製呼叫持續時間的機制不適合移動平臺。但如果你喜歡舊的行為，你可以將Settings > Profiling > Timer query type改回繪製呼叫。
3. 最佳化級別
當你透過RenderDoc啟動應用時，它會用自己的API呼叫替換應用的API呼叫，以記錄為生成幀而發出的所有命令。為了提取要在UI中顯示的資源和狀態，RenderDoc有時需要插入或更改命令。所以，RenderDoc的播放有時會包含phantom操作。為了在分析過程中最小化這個問題，當你選擇profiling mode replay context時，我們強制將最佳化級別設定為最快。作為副作用，部分資源在剖析模式下會顯示為黑色。如果需要同時檢查所述資源和概要檔案，可以使用主線RenderDoc開啟capture，同時使用profiling mode replay context開啟相同的capture檔案。如果你的capture足夠小，可以同時在記憶體中容納兩個副本，你將能能夠同時分析和檢查資源。
由於我們在使用profiling mode replay context時強制設定為Fastest，所以建議你將設定保持為Balanced，以便在使用非profiling mode replay context時方便地檢查資源。
4. GLES/Vulkan API錯誤
在開始任何效能調查之前，你應該檢查應用的API錯誤，因為我們所有的效能工具都需要有效的命令stream。無效的命令stream或錯誤的命令將導致API錯誤，併產生未定義的行為，如崩潰或效能差。自v29以來，我們的作業系統版本中包含了Vulkan驗證層支援；你可以透過命令列或RenderDoc使用它們。
5. RenderDoc API驗證
若要檢查應用是否存在API錯誤，請在開啟capture播放時啟用API驗證。請注意，我們已經禁用了在profiling mode replay context中啟用API驗證的功能。這是因為我們希望在使用RenderDoc for Oculus進行評測時儘可能減少開銷。
在啟用API驗證開啟capture後，RenderDoc檢測的所有API錯誤將顯示在錯誤和警告面板之下。
6. Tile Timeline和Tile Browser
若應用沒有API錯誤，我們就可以依靠RenderDoc for Oculus的Tile Timeline功能在渲染過程中檢查不必要的儲存或載入。
Quest和Quest 2的Tile架構GPU透過Tile渲染最佳化記憶體頻寬使用。每個Tile都可以透過GPU的快速記憶體臨時儲存和訪問多次，並且只需向較慢的記憶體寫入一次。所以，移動VR應用利用這種最佳化非常重要。
RenderDoc for Oculus的Tile Timeline功能顯示了高通GPU在渲染場景時所經歷的不同階段。
你可能會注意到，一些bin比其他大，這是由於Tile打包，其中與周邊視覺對應的Tile被合併，並以較低的解析度渲染。另外，熱圖覆蓋可能會過度擴充套件幀緩衝區的尺寸。這是由於幀緩衝區尺寸未與bin尺寸對齊。這種部分佔用的邊緣bin使用自定義scissor test來消除超出邊界畫素的工作負載。
你另外可能會注意到，從Tile Timeline報告的幀時間可能比持續時間計時器或其他幀時間測量方法報告的幀時間有著更高的成本。這是因為收集定時資訊和屬性的行為會帶來開銷，並且由於渲染階段數量很大，開銷會顯著增加。然後，Quest 2的解析階段（例如顏色寫入或深度寫入）可以與渲染操作重疊。這種同時執行渲染的能力會產生相當大的開銷，並且會影響效能度量。
7. phantom屬性
如前所述，RenderDoc有時會根據需要在播放過程中更改操作。這有時會影響計時測量，所以仔細檢查播放命令並確保它們與應用正在執行的操作相匹配非常重要。
上面是來自同一UE4 Vulkan應用的兩組曲面屬性。左側是Perfetto捕獲的曲面屬性，右側是 RenderDoc for Oculus捕獲的RenderDoc的曲面屬性。左側的顏色attachment屬性顯示“Tiled | UBWC”，右側顯示0。UBWC是指高通的Universal Bandwidth Compression。它不是可以為幀緩衝區設定的Vulkan/GL屬性，而是在幀緩衝區配置滿足UBWC的要求時的選擇。UBWC幀緩衝區attachment的要求之一是，不使用VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT flag建立影象，但RenderDoc會插入它以提取MSAA內容。這是一個可以解決的問題，但需要一定的時間進行解決。
需要強調的是，你從RenderDoc for Oculus獲得的測量值可能不是應用的精確重播，你應該從多個來源獲取測量值。
8. Oculus Performance Counters
在確保應用充分利用Tile架構後，我們可以檢視單個繪製呼叫效能。由於繪製呼叫在Tile GPU中執行的方式，我們不能依賴效能查詢來比較繪製呼叫。相反，我們可以在Performance Counters Viewer下使用特定於Oculus的硬體計數器。
Renderdoc中目前有49個指標可用於Oculus Performance Counters。最重要的指標之一是GPU時鐘指標。當 RenderDoc for Oculus為Oculus Performance Counters查詢時，繪製呼叫將逐個執行，沒有並行性。對於GPU執行操作的每個週期，GPU時鐘計數器將遞增一。佔用更多儲存bin的繪製呼叫自然具有更大的GPU時鐘度量，因為儲存bin一次處理一個。GPU時鐘度量是對繪製呼叫延遲而不是吞吐量的度量。在正常執行環境中，裝置將採用各種延遲隱藏技術，這可能導致許多操作的重疊。所以，重要的是不要過度索引GPU時鐘指標，因為延遲隱藏技術對於實現應用的高效能同樣至關重要。
百分比時間度量可以幫助你瞭解繪製呼叫在vertex階段和fragment階段之間的成本分佈。對於計算shader dispatc， %Time Compute 度量應接近100%。這三個指標的總和應達到100%，表示繪製呼叫花費的總時間。
在知道會知道是vertex bound還是fragment bound後，我們可以檢查著色器呼叫度量，看看是否需要最佳化著色器本身。vertex著色器成本高可能是由於vertex計數高或vertex著色器本身的複雜性。類似地，對於frament著色器，成本可能是由於fragment的數量或著色器本身的複雜性。
除了指令計數外，memory locality差會降低快取的有效性並降低效能。諸如% Vertex Fetch Stall，% Texture Fetch Stall，L1 Texture Cache Miss Per Pixel，% Texture L1 Miss，% Texture L2 Miss，% Stalled on System Memory等的記憶體指標衡量記憶體操作造成的負面影響。所述指標衡量記憶體操作對呼叫的影響。要查明繪製呼叫中的問題，你需要下一組指標。
Per-Shader Metrics可以告訴你著色器使用了多少紋理提取、算術運算和基本函式操作。“Textures / Vertex”或“Textures / Fragment”度量值較高，加上“Vertices Shaded”或“Fragments Shaded”度量值較高，這可能會導致較高的“% Vertex Fetch Stall”或“% Texture Fetch Stall”。請注意，SSBO或R/W緩衝區操作視為紋理操作，可以增加“Textures / Vertex”或“Textures / Fragment”。“ALU/Vertex”和“ALU/Fragment”度量衡量著色器使用的算術運算量。最後，“EFU/Vertex”和“EFU/Fragment”衡量基本函式操作的數量，例如正弦/餘弦。
9. 著色器編輯
標準RenderDoc包含著色器編輯功能，我們可以利用它來進行快速著色器實驗，而無需重建應用。若要使用所述功能，請確保著色器處理工具路徑指向有效路徑。在Settings>Shader Viewer下面，選擇你的路徑並單擊Edit：
正確設定著色器處理工具路徑後，你可以導航到著色器以更改著色器，單擊編輯開啟編輯著色器模組面板。
完成更改後，單擊“重新整理”按鈕編譯著色器以使更改生效。在關閉“編輯著色器模組”面板之前，後續剖析測量將反映所做的更改。
10. 演示
下面這個影片演練利用了Renderdoc for Oculus中的所有剖析功能。
0：00-啟動剖析模式並載入capture
0：30-Tile Timeline和Tile Browser
3：10-Oculus Performance Counters
7：10-著色器編輯和分析
11. 結語
創造引人入勝的沉浸式虛擬現實體驗需要對平臺有深刻的理解。我們將繼續對工具集進行升級和改進，以反映平臺的效能特徵。