隨著光線追蹤成為現代游戲引擎中的主要渲染技術，單個 GPU RayGen 著色器現在可以執行幀的大部分光線模擬。為了管理這種復雜程度，有必要在 HLSL 或 GLSL 源代碼級別觀察著色器性能的分解。因此，著色器分析器現在是優化光線追蹤的必備工具。
在本文中，我將向您展示如何使用 NVIDIA Nsight Graphics 的 GPU Trace Profiler 來分析低級別的著色器性能，以及如何啟用 DirectX 編譯器 (DXC) 的調試信息選項 -Zi。在整個博文中，我將使用以下縮寫：
- DirectX 12 演示應用 NVIDIA RTX 路徑追蹤 SDK v1.2.0，使用默認設置，在全屏模式下，分辨率設置為 1080 像素。
- 公開了 Windows 版本的 NVIDIA Nsight Graphics，版本為 2023.4。
- GeForce RTX 4080 顯卡 驅動版本為 546.33。
沒有著色器調試信息的 GPU Trace
Path Tracing SDK 示例使用嵌入式著色器調試信息編譯所有著色器 (-Zi) 作為 DXC 命令行選項，CMake 文件 中進行了配置。如果不需要 -Zi 選項，可以從 Visual Studio 解決方案中刪除它并進行重建。
我還使用默認設置 (啟用了 Real-Time Shader Profiler 并鎖定了 GPU 時鐘)，從修改后的 Path Tracing SDK 演示應用中生成了 GPU Trace。圖 1 展示了在選中 PathTrace 標記的工具中的效果。
熱點不顯示任何 HLSL，僅顯示 DXIL 鏈接。單擊頂部熱點的 DXIL 鏈接，工具會跳轉到 DXIL 行，Sample%和Stall reason%s要知道此線映射到哪條 HLSL 線很有挑戰性 (圖 2)。
查看底部面板中的 Shader Pipelines 選項卡 (圖 3)，可以看到相關列包含以下警告：“Shader bytecode not contain debug info，recompile the shader with enabled debug info to 解決此問題。”
GPU Trace Profiler 在 SASS 級別收集其著色器分析數據，SASS 是在 GPU 上執行的低級指令集。它始終可以將 SASS 級別的分析數據與 DXIL (或 SPIR-V) 中間語言關聯起來。
但是，要使 GPU Trace Profiler 將分析數據與高級語言 (HLSL 或 GLSL) 關聯，DXIL 必須包含著色器調試信息。具體來說，DXIL 必須包含 HLSL 源代碼和將 HLSL 行與 DXIL 行關聯的行表。請參閱 著色器編譯部分，了解如何在 NVIDIA Nsight Graphics 用戶指南中根據 HLSL 的編譯方式啟用著色器調試信息。
在開發過程中，我建議將著色器調試信息嵌入到 DXIL Blob 中。也就是說，使用 -Zi -Qembed_debug 而不是著色器 PDB，這樣您的 GPU Trace 文件就是獨立的。有關詳細信息，請參閱 microsoft/DirectXShaderCompiler 在 GitHub 上發布。
使用此方法時，您無需手動跟蹤使用哪種追蹤的著色器 PDB.如果嵌入著色器調試信息會導致 DXIL Blob 過大或出現問題，您還可以配置 DXC，將著色器調試信息作為單獨的著色器 PDB 文件寫入到文件夾中，-Zi和-FdDXC 選項。在這種情況下，您需要在加載 GPU Trace 文件之前，在 Nsight Graphics Options 中配置單獨著色器調試信息的搜索路徑。
包含著色器調試信息的 GPU Trace
圖 4 展示了在 Visual Studio 解決方案中使用原始版本重建演示應用后的 Shader Pipelines 部分，以及 DXC 命令行參數 -Zi -Qembed_debug，用于光線追蹤著色器。這些設置通過 GPU Trace Profiler 捕捉了新的追蹤。
-Zi“Shader Pipelines”(著色器管線) 部分通過單擊“Bottom-Up Calls”(自下而上調用) 選項卡，您現在可以輕松查看昂貴的 HLSL 函數、它們執行的 GPU 工作類型以及在較高水平限制它們的因素 (圖 5)。請注意，在未加載調試符號時，不存在“Bottom – Up Calls”(自下而上調用) 選項卡以及“Top – down Calls”(自上而下調用) 選項卡。
在本示例中，“Bottom-Up Calls”(自下而上調用) 部分中的第三個 HLSL 函數是隨機數生成器，bhos_sobol獲取 4.5%的 PathTrace 標記，以及 60%的 HLSL 函數的頂部問題停滯 (NOINST) (通常等待指令緩存丟失)。
在圖 6 中，HLSL 視圖顯示，展開循環的主體是產生所有延遲的地方，頂部 SM 問題停滯原因是 NOINST.這可以通過存在多次迭代的展開循環來解釋，該循環會生成許多硬件指令，并對 GPU 的指令緩存造成壓力。
bhos_sobol函數由于指令緩存受限，此函數的一種可能優化策略是在結構化緩沖區中預計算其輸出值。SDK 版本 v1.2.0 已支持此路徑，盡管默認情況下未啟用此路徑。
// In Config.h
#define USE_PRECOMPUTED_SOBOL_BUFFER 1 // see NoiseAndSequences.hlsli - still experimental, faster but lower quality and more RAM - not a clear win
// In NoiseAndSequences.hlsli
uint bhos_sobol(uint index, uniform uint dimension)
{
return SOBOL_PRECOMPUTED_BUFFER[ (index % SOBOL_PRECOMPUTED_INDEX_COUNT) + SOBOL_PRECOMPUTED_INDEX_COUNT * dimension ];
}
結束語
在使用 NVIDIA Nsight Graphics GPU Trace 的實時著色器分析器時，請確保在右下角面板的“Shader Pipelines”部分中，所有著色器都已啟用 HLSL 相關。如果發現有樣本顯著但 HLSL 相關缺失的著色器，請按照 NVIDIA Nsight Graphics 用戶指南中的說明，在啟用調試信息的情況下重新編譯這些著色器。然后，捕捉一個新的 GPU 追蹤。
相較于在啟用 HLSL 關聯的情況下重新運行，嘗試在不使用 HLSL 關聯的情況下使用著色器分析器數據將節省時間。HLSL 調試數據對于 Nsight Graphics Shader Debugger 等未來功能至關重要，使您能夠正確調試著色器代碼，以及 NVIDIA Nsight Aftermath。
致謝
我要感謝 Aurelio Reis、Avinash Baliga、Axel Mamode、Robert Jensen、Iain Cantlay、Filip Strugar、Ivan Fedorov 和 Juha Sjoholm 為本文做出的貢獻。
?
