如何通過RenderDoc優(yōu)化Quest VR應用

　　RenderDoc是一個支持Android的開源調(diào)試器，可幫助你窺視應用渲染機制幕后情況。對于商用游戲引擎，實際的渲染代碼要么是隱藏，要么難以通過于各種內(nèi)置子系統(tǒng)來解密，所以如果能夠看到引擎是如何確定場景在單幀中的渲染方式，何樂而不為呢?

　　當你通過RenderDoc捕獲一幀時，它會按照幀的發(fā)出順序記錄所有圖形API命令和資源，然后再播放它們。RenderDoc同時可以幫助你大致知曉GPU執(zhí)行繪制需要多少時間和繪制邏輯組。

　　關于RenderDoc的另一個關鍵要點是，它完全免費，并且開源。具體請訪問官方的RenderDoc下載頁面。

　　映維網(wǎng)早前已經(jīng)分享過一系列通過RenderDoc優(yōu)化Oculus Quest應用的博文。現(xiàn)在，Meta開發(fā)者團隊又介紹了與之相關的主題技巧，下面是映維網(wǎng)的具體整理：

　　RenderDoc for Oculus是熱門圖形調(diào)試器RenderDoc的定制分支。這個特定于Quest的工具提供了對底層GPU剖析數(shù)據(jù)的訪問，特別是來自Tile渲染器的信息。我們正繼續(xù)改進工具，并增加了一系列德新功能，如Tile Browser和Oculus Performance Counters。深度剖析功能和各種圖形調(diào)試功能令RenderDoc for Oculus成為了解決性能難題的一個重要工具。在這篇博文中，我們將回顧如何有效地利用RenderDoc for Oculus，以及你應該避免的陷阱。

　　1. 開始

　　RenderDoc for Oculus這個圖形調(diào)試器允許你快速輕松地捕獲單幀，并詳細檢查任何應用。如果是剛剛接觸，你可以參閱下面的博文：

　　延伸閱讀：研發(fā)實戰(zhàn)一：如何通過RenderDoc優(yōu)化Oculus Quest應用

　　延伸閱讀：研發(fā)實戰(zhàn)二：如何通過RenderDoc優(yōu)化Oculus Quest應用

　　延伸閱讀：研發(fā)實戰(zhàn)三：如何通過RenderDoc優(yōu)化Oculus Quest應用

　　延伸閱讀：研發(fā)實戰(zhàn)四：如何通過RenderDoc優(yōu)化Oculus Quest應用

　　對于已經(jīng)十分熟悉RenderDoc For Oculus的用戶，我們現(xiàn)在將深入探討如何充分利用這個工具。

　　2. 計時器按鈕行為

　　計時器按鈕是RenderDoc最熱門的功能之一，因為它簡單易用。從v23.2開始，我們改動計時器按鈕行為以進行渲染通道測量，而不是繪制調(diào)用測量。這一變化的原因是性能查詢：因為基于Tile的GPU架構(gòu)，RenderDoc用于測量每次繪制調(diào)用持續(xù)時間的機制不適合移動平臺。但如果你喜歡舊的行為，你可以將Settings > Profiling > Timer query type改回繪制調(diào)用。

　　3. 優(yōu)化級別

　　當你通過RenderDoc啟動應用時，它會用自己的API調(diào)用替換應用的API調(diào)用，以記錄為生成幀而發(fā)出的所有命令。為了提取要在UI中顯示的資源和狀態(tài)，RenderDoc有時需要插入或更改命令。所以，RenderDoc的播放有時會包含phantom操作。為了在分析過程中最小化這個問題，當你選擇profiling mode replay context時，我們強制將優(yōu)化級別設置為最快。作為副作用，部分資源在剖析模式下會顯示為黑色。如果需要同時檢查所述資源和概要文件，可以使用主線RenderDoc打開capture，同時使用profiling mode replay context打開相同的capture文件。如果你的capture足夠小，可以同時在內(nèi)存中容納兩個副本，你將能能夠同時分析和檢查資源。

　　由于我們在使用profiling mode replay context時強制設置為Fastest，所以建議你將設置保持為Balanced，以便在使用非profiling mode replay context時方便地檢查資源。

　　4. GLES/Vulkan API錯誤

　　在開始任何性能調(diào)查之前，你應該檢查應用的API錯誤，因為我們所有的性能工具都需要有效的命令stream。無效的命令stream或錯誤的命令將導致API錯誤，并產(chǎn)生未定義的行為，如崩潰或性能差。自v29以來，我們的操作系統(tǒng)版本中包含了Vulkan驗證層支持;你可以通過命令行或RenderDoc使用它們。

　　5. RenderDoc API驗證

　　若要檢查應用是否存在API錯誤，請在打開capture播放時啟用API驗證。請注意，我們已經(jīng)禁用了在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架構(gòu)GPU通過Tile渲染優(yōu)化內(nèi)存帶寬使用。每個Tile都可以通過GPU的快速內(nèi)存臨時存儲和訪問多次，并且只需向較慢的內(nèi)存寫入一次。所以，移動VR應用利用這種優(yōu)化非常重要。

　　RenderDoc for Oculus的Tile Timeline功能顯示了高通GPU在渲染場景時所經(jīng)歷的不同階段。

　　你可能會注意到，一些bin比其他大，這是由于Tile打包，其中與周邊視覺對應的Tile被合并，并以較低的分辨率渲染。另外，熱圖覆蓋可能會過度擴展幀緩沖區(qū)的尺寸。這是由于幀緩沖區(qū)尺寸未與bin尺寸對齊。這種部分占用的邊緣bin使用自定義scissor test來消除超出邊界像素的工作負載。

　　你另外可能會注意到，從Tile Timeline報告的幀時間可能比持續(xù)時間計時器或其他幀時間測量方法報告的幀時間有著更高的成本。這是因為收集定時信息和屬性的行為會帶來開銷，并且由于渲染階段數(shù)量很大，開銷會顯著增加。然后，Quest 2的解析階段(例如顏色寫入或深度寫入)可以與渲染操作重疊。這種同時執(zhí)行渲染的能力會產(chǎn)生相當大的開銷，并且會影響性能度量。

　　7. phantom屬性

　　如前所述，RenderDoc有時會根據(jù)需要在播放過程中更改操作。這有時會影響計時測量，所以仔細檢查播放命令并確保它們與應用正在執(zhí)行的操作相匹配非常重要。

　　上面是來自同一UE4 Vulkan應用的兩組曲面屬性。左側(cè)是Perfetto捕獲的曲面屬性，右側(cè)是 RenderDoc for Oculus捕獲的RenderDoc的曲面屬性。左側(cè)的顏色attachment屬性顯示“Tiled | UBWC”，右側(cè)顯示0。UBWC是指高通的Universal Bandwidth Compression。它不是可以為幀緩沖區(qū)設置的Vulkan/GL屬性，而是在幀緩沖區(qū)配置滿足UBWC的要求時的選擇。UBWC幀緩沖區(qū)attachment的要求之一是，不使用VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT flag創(chuàng)建圖像，但RenderDoc會插入它以提取MSAA內(nèi)容。這是一個可以解決的問題，但需要一定的時間進行解決。

　　需要強調(diào)的是，你從RenderDoc for Oculus獲得的測量值可能不是應用的精確重播，你應該從多個來源獲取測量值。

　　8. Oculus Performance Counters

　　在確保應用充分利用Tile架構(gòu)后，我們可以查看單個繪制調(diào)用性能。由于繪制調(diào)用在Tile GPU中執(zhí)行的方式，我們不能依賴性能查詢來比較繪制調(diào)用。相反，我們可以在Performance Counters Viewer下使用特定于Oculus的硬件計數(shù)器。

　　Renderdoc中目前有49個指標可用于Oculus Performance Counters。最重要的指標之一是GPU時鐘指標。當 RenderDoc for Oculus為Oculus Performance Counters查詢時，繪制調(diào)用將逐個執(zhí)行，沒有并行性。對于GPU執(zhí)行操作的每個周期，GPU時鐘計數(shù)器將遞增一。占用更多存儲bin的繪制調(diào)用自然具有更大的GPU時鐘度量，因為存儲bin一次處理一個。GPU時鐘度量是對繪制調(diào)用延遲而不是吞吐量的度量。在正常執(zhí)行環(huán)境中，設備將采用各種延遲隱藏技術，這可能導致許多操作的重疊。所以，重要的是不要過度索引GPU時鐘指標，因為延遲隱藏技術對于實現(xiàn)應用的高性能同樣至關重要。

　　百分比時間度量可以幫助你了解繪制調(diào)用在vertex階段和fragment階段之間的成本分布。對于計算shader dispatc， %Time Compute 度量應接近100%。這三個指標的總和應達到100%，表示繪制調(diào)用花費的總時間。

　　在知道會知道是vertex bound還是fragment bound后，我們可以檢查著色器調(diào)用度量，看看是否需要優(yōu)化著色器本身。vertex著色器成本高可能是由于vertex計數(shù)高或vertex著色器本身的復雜性。類似地，對于frament著色器，成本可能是由于fragment的數(shù)量或著色器本身的復雜性。

　　除了指令計數(shù)外，memory locality差會降低緩存的有效性并降低性能。諸如% Vertex Fetch Stall，% Texture Fetch Stall，L1 Texture Cache Miss Per Pixel，% Texture L1 Miss，% Texture L2 Miss，% Stalled on System Memory等的內(nèi)存指標衡量內(nèi)存操作造成的負面影響。所述指標衡量內(nèi)存操作對調(diào)用的影響。要查明繪制調(diào)用中的問題，你需要下一組指標。

　　Per-Shader Metrics可以告訴你著色器使用了多少紋理提取、算術運算和基本函數(shù)操作。“Textures / Vertex”或“Textures / Fragment”度量值較高，加上“Vertices Shaded”或“Fragments Shaded”度量值較高，這可能會導致較高的“% Vertex Fetch Stall”或“% Texture Fetch Stall”。請注意，SSBO或R/W緩沖區(qū)操作視為紋理操作，可以增加“Textures / Vertex”或“Textures / Fragment”。“ALU/Vertex”和“ALU/Fragment”度量衡量著色器使用的算術運算量。最后，“EFU/Vertex”和“EFU/Fragment”衡量基本函數(shù)操作的數(shù)量，例如正弦/余弦。

　　9. 著色器編輯

　　標準RenderDoc包含著色器編輯功能，我們可以利用它來進行快速著色器實驗，而無需重建應用。若要使用所述功能，請確保著色器處理工具路徑指向有效路徑。在Settings>Shader Viewer下面，選擇你的路徑并單擊Edit：

　　正確設置著色器處理工具路徑后，你可以導航到著色器以更改著色器，單擊編輯打開編輯著色器模塊面板。

　　完成更改后，單擊“刷新”按鈕編譯著色器以使更改生效。在關閉“編輯著色器模塊”面板之前，后續(xù)剖析測量將反映所做的更改。

　　10. 演示

　　下面這個視頻演練利用了Renderdoc for Oculus中的所有剖析功能。

　　0:00-啟動剖析模式并加載capture

　　0:30-Tile Timeline和Tile Browser

　　3:10-Oculus Performance Counters

　　7:10-著色器編輯和分析

　　11. 結(jié)語

　　創(chuàng)造引人入勝的沉浸式虛擬現(xiàn)實體驗需要對平臺有深刻的理解。我們將繼續(xù)對工具集進行升級和改進，以反映平臺的性能特征。