優(yōu)化任何GPU工作負(fù)載的峰值性能分析方法

弄清楚如何在個(gè)人電腦上降低渲染應(yīng)用程序的GPU幀時(shí)間可能是一項(xiàng)具有挑戰(zhàn)性的任務(wù)，即使是最有經(jīng)驗(yàn)的PC游戲開(kāi)發(fā)人員也是如此。本博客文章描述了我們?cè)贜VIDIA內(nèi)部使用的性能分類(lèi)方法，使用NVIDIA特定的硬件度量標(biāo)準(zhǔn)來(lái)找出任何給定GPU工作負(fù)載（也稱(chēng)為性能標(biāo)記或調(diào)用范圍）的主要性能限制器。

我們的性能分類(lèi)方法并非從假設(shè)或有關(guān)在GPU上呈現(xiàn)的內(nèi)容的知識(shí)開(kāi)始。相反，它僅從硬件指標(biāo)開(kāi)始，讓我們知道整個(gè)GPU的利用情況，哪些硬件單元和子單元限制了性能，以及它們運(yùn)行到各自的峰值性能的接近程度（也稱(chēng)為“速度光“或”SOL“）。如果應(yīng)用程序不使用異步計(jì)算，則可以將此以硬件為中心的信息映射回圖形API和著色器正在執(zhí)行的操作，從而為如何提高任何給定工作負(fù)載的GPU性能提供指導(dǎo)：

1. 如果沒(méi)有GPU單元具有較高的吞吐量（與SOL相比），那么我們會(huì)努力提高至少一個(gè)單元的吞吐量。

2. 如果一些GPU單元具有較高的吞吐量（與SOL相比），那么我們將弄清楚如何從該單元中刪除工作。

Nsight Range Profiler

從開(kāi)普勒架構(gòu)1（完全支持Maxwell，Pascal和VoltaGPU）開(kāi)始，所有NVIDIA GPU上的DX11，DX12和OpenGL上的PerfWorks庫(kù)可以捕獲每個(gè)GPU工作負(fù)載的硬件指標(biāo)。雖然PerfWorks頭文件尚未公開(kāi)，但該庫(kù)現(xiàn)在可以通過(guò)公共工具使用：Nsight的Range Profiler：用于DX12，DX11和OpenGL 4.6（但不包括Vulkan）的Visual Studio Edition 5.5，以及Microsoft的“PIX在Windows上“用于DX12。

1從維基百科上可以看到，GeForce 600和700系列大多是開(kāi)普勒，900系列是麥克斯韋，1000系列是帕斯卡，而TITAN V是沃爾塔。

第1步：鎖定GPU核心時(shí)鐘

首先，為了獲得最具確定性的測(cè)量結(jié)果，我們建議您在收集任何性能指標(biāo)之前始終鎖定您的GPU核心時(shí)鐘頻率（并在解鎖之后進(jìn)行解鎖，以獲得最佳性能，以及在GPU空閑或只是最小化功耗和噪聲時(shí)做桌面渲染）。在啟用了“開(kāi)發(fā)者模式”的Windows 10上，可以通過(guò)運(yùn)行一個(gè)簡(jiǎn)單的DX12應(yīng)用程序來(lái)完成此操作，該應(yīng)用程序在虛擬DX12設(shè)備上調(diào)用SetStablePowerState（TRUE），然后在不釋放設(shè)備的情況下進(jìn)入睡眠狀態(tài)，如本博文所述。

注意：從Nsight：Visual Studio版本5.5開(kāi)始，Range Profiler現(xiàn)在可以在分析任何Range之前/之后有效地調(diào)用SetStablePowerState（），使用適用于所有Windows版本（不僅僅是Windows 10）的內(nèi)部驅(qū)動(dòng)程序API，也不需要操作系統(tǒng)將處于“開(kāi)發(fā)者模式”。因此，在使用Nsight Range Profiler時(shí)，您不必?fù)?dān)心鎖定GPU Core時(shí)鐘。

第2步：用Nsight HUD捕捉畫(huà)面

對(duì)于非UWP（通用Windows平臺(tái)）應(yīng)用程序，這可以通過(guò)將您的EXE（或批處理文件）拖放到Nsight安裝在桌面上的“NVIDIA Nsight HUD啟動(dòng)器”快捷方式來(lái)完成，并達(dá)到您想要的游戲位置捕捉，然后：

1. 按CTRL-Z在屏幕的右上部分顯示Nsight HUD，并

2. 點(diǎn)擊Nsight HUD中的“暫停和捕捉幀”按鈕，或者按空格鍵開(kāi)始捕捉。

您可以通過(guò)單擊“將捕獲保存到磁盤(pán)”按鈕將當(dāng)前幀導(dǎo)出到Visual Studio C ++項(xiàng)目。（默認(rèn)情況下，Nsight導(dǎo)出的幀被保存到C： Users ... Documents NVIDIA Nsight Captures ...）

你可以點(diǎn)擊“恢復(fù)”繼續(xù)玩你的游戲，以便找到你想要捕捉更多幀的其他位置。

注意：您可以跳過(guò)“將捕獲保存到磁盤(pán)”步驟并直接跳到下一步（Scrubber＆Range Profiler分析），但我們建議始終將捕獲保存到磁盤(pán)，并將它們存檔，以便可以返回到它們你需要稍后。將導(dǎo)出的幀保存到磁盤(pán)可讓您稍后將數(shù)據(jù)附加到分析中，以便您或團(tuán)隊(duì)中的其他人員可以嘗試重現(xiàn)您的結(jié)果。

在NVIDIA?（英偉達(dá)?）中，我們將性能分析視為一個(gè)科學(xué)流程，我們提供與分析相關(guān)的所有repro數(shù)據(jù)，并鼓勵(lì)同事重新繪制并審核我們的結(jié)果。根據(jù)我們的經(jīng)驗(yàn)，在進(jìn)行性能優(yōu)化嘗試（無(wú)論是否成功）之前和之后捕獲幀也是一種很好的做法，分析硬件度量標(biāo)準(zhǔn)如何變化并從結(jié)果中學(xué)習(xí)。

關(guān)于Nsight幀捕獲的補(bǔ)充說(shuō)明：

• 對(duì)于Nsight框架，無(wú)論您的應(yīng)用程序是以窗口模式，全屏模式還是全屏無(wú)邊界模式運(yùn)行都無(wú)所謂，因?yàn)镹sight總是在隱藏窗口中運(yùn)行框架。只要確保分辨率和圖形設(shè)置是你想要分析的。

• 對(duì)于DX12應(yīng)用程序，我們假設(shè)沒(méi)有使用異步計(jì)算，否則某些硬件度量可能會(huì)受到GPU上多個(gè)同時(shí)執(zhí)行的工作負(fù)載的影響。到目前為止，對(duì)于所有基于PerfWorks的分析，我們建議禁用在DX12應(yīng)用程序中使用異步計(jì)算。

• 關(guān)于DX12異步復(fù)制調(diào)用（在COPY隊(duì)列中），可以在幀捕獲中使用這些調(diào)用，但是您應(yīng)該知道，PerfWorks和Nsight目前不會(huì)單獨(dú)分析COPY隊(duì)列調(diào)用。因此，與其他DIRECT隊(duì)列調(diào)用并行執(zhí)行的任何COPY隊(duì)列調(diào)用都可能會(huì)影響這些工作負(fù)載中的GPU DRAM流量。

• 將該exe文件拖放到“Nsight HUD啟動(dòng)器”將不適用于UWP應(yīng)用程序。在對(duì)UWP Nsight推出的做法，目前只能通過(guò)Visual Studio IDE中的支持。

第3步：分解GPU幀時(shí)間

GPU時(shí)間的自頂向下查看是找出哪些性能指標(biāo)/工作負(fù)載在一個(gè)幀中最昂貴的好方法。對(duì)于HBAO +DX11測(cè)試應(yīng)用程序，在GeForce GTX 1060 6GB上渲染SSAO為4K，在Nsight的Scrubber中，GPU幀時(shí)間分解如下所示：

圖1. Nsight中Scrubber的示例GPU幀時(shí)間細(xì)分：Visual Studio Edition 5.5。

在“Perf Markers”行中，Scrubber顯示通過(guò)D3D時(shí)間戳查詢(xún)測(cè)量的每個(gè)工作負(fù)載的GPU時(shí)間，以及每個(gè)工作負(fù)載正在使用的GPU幀時(shí)間百分比（排除當(dāng)前調(diào)用）。在圖1的例子中，這一幀中哪個(gè)工作負(fù)載最為昂貴是顯而易見(jiàn)的：“DrawCoarseAOPS”，占GPU時(shí)間的49.1％。

注意：要重新顯示此結(jié)果，可以從GitHub下載HBAO +源代碼版本3.1，然后在Visual Studio中運(yùn)行“SampleApp_D3D11”項(xiàng)目。要使RenderAO調(diào)用發(fā)出性能標(biāo)記，可以在GFSDK_SSAO_D3D11 - >項(xiàng)目屬性 - > C / C + - >預(yù)處理器中定義ENABLE_PERF_MARKERS = 1。為了記錄，這里是框架的樣子：

步驟4：?jiǎn)?dòng)Nsight Range Profiler

您可以打開(kāi)您在步驟2中導(dǎo)出到磁盤(pán)的幀捕獲的Visual Studio解決方案文件，在Release x64中構(gòu)建解決方案，然后轉(zhuǎn)到Visual Studio中的Nsight菜單，然后單擊“開(kāi)始圖形調(diào)試”。

要到達(dá)Nsight Range Profiler，您可以啟動(dòng)Nsight幀捕捉EXE，然后：

1. 按CTRL-Z然后按空格鍵

2. ALT-Tab到您的Visual Studio窗口

3. 找到Nsight在那里添加的Scrubber選項(xiàng)卡

4. 右鍵單擊您想要分析的工作負(fù)載，然后單擊“Profile [Perf Markers] ...”

注意：如果由于某種原因，CTRL-Z + SPACE不適用于您的應(yīng)用程序，您可以ALT-Tab到Visual Studio，然后單擊Visual Studio - > Nsight菜單 - >“暫停和捕獲幀”。

我們通過(guò)右鍵單擊洗滌器中的“DrawCoarseAOPS”框并執(zhí)行“Profile [Perf Markers] DrawCoarseAOPS”，從步驟3的“DrawCoarseAOPS”工作負(fù)載調(diào)用Range Profiler（僅通過(guò)分析此調(diào)用范圍，除此之外別無(wú)其他）

圖2.從Scrubber窗口為給定的工作負(fù)載啟動(dòng)Nsight Range Profiler。

Range Profiler在Nsight幀捕獲中注入PerfWorks調(diào)用，并為指定的工作負(fù)載收集一組PerfWorks度量。分析完成后，Nsight將在Scrubber下方的Range Profiler窗口的新部分中顯示收集的度量標(biāo)準(zhǔn)。

第5步：檢查頂級(jí)SOL和高速緩存命中率

我們首先檢查Range Profiler的“Pipeline Overview”Summary部分的指標(biāo)。這只是PerfWorks衡量當(dāng)前工作負(fù)載的一個(gè)視圖。通過(guò)將鼠標(biāo)懸停在任何指標(biāo)上，實(shí)際的Perfworks指標(biāo)名稱(chēng)將顯示在工具提示中：

圖3.顯示PerfWorks度量名稱(chēng)和描述的Nsight Range Profiler工具提示。

5.1。每單位SOL％度量標(biāo)準(zhǔn)

要查看每個(gè)工作負(fù)載的首要頂級(jí)指標(biāo)是GPU的每單元SOL％指標(biāo)。這些傳達(dá)了每個(gè)單元與其最大理論吞吐量或光速（SOL）的接近程度。在高層次上，可以將每單元SOL％度量設(shè)想為實(shí)現(xiàn)的吞吐量與SOL吞吐量的比率。但是，對(duì)于具有多個(gè)子單元或并發(fā)數(shù)據(jù)路徑的單元，每單元SOL％是所有子單元和數(shù)據(jù)路徑的所有子SOL標(biāo)準(zhǔn)的最大值。

注：如果您不熟悉GPU中設(shè)備的名稱(chēng)，請(qǐng)閱讀以下博客文章，其中提供了邏輯圖形管道如何映射到GPU架構(gòu)中的GPU單元的高級(jí)概述：“三角形的壽命- NVIDIA的邏輯管道“，以及GTC 2016演示文稿中的第7至第25張幻燈片：”GPU驅(qū)動(dòng)渲染“。在這種情況下：

• “IA”（Input Assembler）加載索引和頂點(diǎn)（在頂點(diǎn)著色器被調(diào)用之前）。

• SM（流式多處理器）運(yùn)行著色器。

• TEX執(zhí)行SRV提取（和Maxwell以來(lái)的無(wú)人機(jī)訪問(wèn)）。

• L2是連接到每個(gè)DRAM分區(qū)的二級(jí)緩存。

• CROP的顏色寫(xiě)入和混合渲染目標(biāo)。

• ZROP進(jìn)行深度模板測(cè)試。

• DRAM（范圍圖中的“內(nèi)存”）是GPU視頻內(nèi)存。

注意：在Nsight Range Profiler結(jié)果中，通過(guò)在管道概覽中選擇“Range Diagram”，可以找到圖形管道的簡(jiǎn)化視圖及其與GPU單元的映射。在該圖中，每單位SOL％值顯示為綠色條形：

圖4. Nsight Range Profiler：流水線概覽 - >范圍圖。

如圖4所示，當(dāng)今的GPU不是一個(gè)簡(jiǎn)單的線性流水線（A→B→C→...），而是一個(gè)互連單元網(wǎng)絡(luò)（SM < - > TEX < - > L2，SM- > CROP < - > L2等）。簡(jiǎn)單的“瓶頸”計(jì)算依賴(lài)于每個(gè)單元的固定上行和下行接口，但不足以推斷GPU的性能。因此，在進(jìn)行我們的分析時(shí)，我們主要考察每個(gè)單位的SOL％度量，以確定單位和/或限制性能的問(wèn)題。下一節(jié)將詳細(xì)討論這種方法。

5.2。“頂級(jí)SOL單位”

在我們的性能分類(lèi)方法論中，我們始終始于查看前5個(gè)SOL單位及其相關(guān)的SOL％度量。這些是限制此工作負(fù)載的GPU性能的前5個(gè)硬件單元。Nsight Range Profiler在Pipeline Overview - Summary部分顯示前5個(gè)SOL％指標(biāo)（又名“頂級(jí)SOL”），例如：

圖5. Range Profiler中的“Top SOLs”示例 - > Nsight中的Pipeline Overview：Visual Studio Edition 5.5。

情況1：SOL％> 80％

如果頂層SOL％值大于80％，那么我們知道GPU上的配置文件工作負(fù)載運(yùn)行非常高效（接近最大吞吐量），為了加快速度，應(yīng)該嘗試從頂層SOL單元中移除工作，它到另一個(gè)單位。例如，對(duì)于SM作為SOL％> 80％的頂級(jí)SOL單元的工作負(fù)載，可以嘗試機(jī)會(huì)性地跳過(guò)指令組，或考慮將某些計(jì)算移動(dòng)到查找表。另一個(gè)例子是將結(jié)構(gòu)化緩沖區(qū)加載移動(dòng)到在統(tǒng)一訪問(wèn)結(jié)構(gòu)化緩沖區(qū)（所有線程加載來(lái)自相同地址的數(shù)據(jù)）中的著色器中的恒定緩沖區(qū)加載，以及受紋理吞吐量限制的工作負(fù)載（因?yàn)榻Y(jié)構(gòu)化緩沖區(qū)通過(guò)TEX單元加載）。

情況2：頂部SOL％<60％

如果最高SOL％值<60％，這意味著頂級(jí)SOL單元和所有其他具有較低SOL％的GPU單元未充分利用（空閑周期），運(yùn)行效率低下（失速周期），或者未達(dá)到其快速路徑，原因是他們給出的工作量的細(xì)節(jié)。這些情況的例子包括：

• 該應(yīng)用程序部分受CPU限制（參見(jiàn)第6.1.1節(jié)）;

• 大量等待空閑命令或圖形< - >計(jì)算開(kāi)關(guān)反復(fù)排空GPU管線（參見(jiàn)第6.1.2節(jié)）;

• TEX從具有格式，維度或過(guò)濾器模式的紋理對(duì)象中提取數(shù)據(jù)，使其在設(shè)計(jì)時(shí)以較低的吞吐量運(yùn)行（請(qǐng)參閱這些用于GTX 1080的綜合基準(zhǔn)測(cè)試）。例如，當(dāng)采用三線性濾波對(duì)三維紋理進(jìn)行采樣時(shí)，預(yù)計(jì)有50％的TEX SOL％;

• 內(nèi)存子系統(tǒng)效率低下，例如TEX或L2單元中高速緩存命中率低，導(dǎo)致DRAM SOL％低的DRAM訪問(wèn)稀疏，VB / IB / CB / TEX從系統(tǒng)內(nèi)存取代GPU DRAM;

• 輸入組件獲取32位索引緩沖區(qū)（半速率與16位索引相比）。

注意：在這種情況下，我們可以使用最高SOL％值來(lái)導(dǎo)出可通過(guò)降低低效率在此工作負(fù)載上實(shí)現(xiàn)的最大增益的上限：如果給定的工作負(fù)載在其SOL的50％處運(yùn)行，并且假設(shè)可以通過(guò)減少內(nèi)部低效率將SOL％提高到90％，我們知道工作負(fù)載的最大預(yù)期收益為90/50 = 1.8x = 80％。

情況3：[60,80]中的最高SOL％

在這種情況下（灰色區(qū)域），我們遵循情況1（高位SOL％）和情況2（低位SOL％）的方法。

注：每單元SOL％度量標(biāo)準(zhǔn)都是相對(duì)于GPU周期（掛鐘）而定義的，這可能與活動(dòng)周期（硬件單元不空閑的周期）不同。我們定義它們相對(duì)于經(jīng)過(guò)周期而不是每單位有效周期的主要原因是通過(guò)給出它們所有的公分母來(lái)使SOL％指標(biāo)具有可比性。定義它們相對(duì)于經(jīng)過(guò)周期的另一個(gè)好處是任何限制整體GPU性能的GPU空閑周期都會(huì)被報(bào)告為該工作負(fù)載的最低SOL％值（我們的SOL引導(dǎo)分類(lèi)中的頂級(jí)度量標(biāo)準(zhǔn)）。

5.3。次要SOL單位和TEX和L2命中率

Nsight Range Profiler報(bào)告前5個(gè)SOL單元的原因不僅僅是最大的一個(gè)，因?yàn)榭赡苡卸鄠€(gè)硬件單元彼此交互，并且都在一定程度上限制了性能。所以我們建議根據(jù)SOL％值手動(dòng)對(duì)SOL單元進(jìn)行聚類(lèi)。（實(shí)際上，10％的增量似乎可以很好地定義這些集群，但我們建議手動(dòng)執(zhí)行集群以避免遺漏任何內(nèi)容。）

注意：我們還建議查看距離分析器“內(nèi)存”部分中顯示的TEX（L1）和L2命中率。一般來(lái)說(shuō)，大于90％的命中率很好，80％到90％之間好，80％以下（可能會(huì)顯著限制性能）。

全屏HBAO +模糊工作負(fù)載與前5個(gè)SOL：

SM：94.5％|TEX：94.5％|L2：37.3％|作物：35.9％|DRAM：27.7％

...既是SM又是TEX限制。由于SM和TEX SOL％值是相同的，我們可以推斷出SM性能很可能受SM和TEX單元之間接口吞吐量的限制：SM請(qǐng)求TEX或TEX將數(shù)據(jù)返回給SM 。

它具有TEX命中率88.9％和L2命中率87.3％。

在“TEX-Interface Limited Workload”附錄中查看此工作負(fù)載的研究。

從HBAO +例子中轉(zhuǎn)移出來(lái)，下面是我們最近分析的一些典型的游戲引擎工作負(fù)載。

具有頂級(jí)SOL的SSR工作負(fù)載：

SM：49.1％|L2：36.8％|TEX：35.8％|DRAM：33.5％|CROP：0.0％

...將SM作為主要限制器，將L2，TEX和DRAM作為次要限制器，TEX命中率為54.6％，L2命中率為76.4％。這種較差的TEX命中率可以解釋SM SOL％較低：由于TEX命中率較差（很可能是由于相鄰像素獲取了很遠(yuǎn)的紋理元素），因此SM看到的平均TEX延遲比通常更高，更具挑戰(zhàn)性隱藏。

注意：這里的活動(dòng)單元實(shí)際上是一個(gè)依賴(lài)鏈：SM - > TEX - > L2 - > DRAM。

此頂級(jí)SOL的GBuffer填充工作負(fù)載：

TEX：54.7％|SM：46.0％|DRAM：37.2％|L2：30.7％|CROP：22.0％

...將TEX和SM作為主要限制器，將DRAM和L2作為次要限制器，TEX命中率為92.5％，L2命中率為72.7％。

這款平鋪照明計(jì)算著色器具有頂級(jí)SOL：

SM：70.4％|L2：67.5％|TEX：49.3％|DRAM：42.6％|CROP：0.0％

...以SM＆L2為主要限制器，TEX＆DRAM為次要限制器，TEX命中率為64.3％，L2命中率為85.2％。

這個(gè)帶有頂級(jí)SOL的陰影貼圖生成工作負(fù)載：

IA：31.6％|DRAM：19.8％|L2：16.3％|VAF：12.4％|CROP：0.0％

...是IA限制的（輸入匯編器）并且具有較低的SOL％。在這種情況下，將索引緩沖區(qū)格式從32位更改為16位有幫助。TEX命中率無(wú)關(guān)緊要，因?yàn)門(mén)EX不在前5名SOL單位中。L2命中率為62.6％。

第6步：了解性能限制器

完成第5步后，我們知道每個(gè)感興趣工作負(fù)載的頂級(jí)SOL單元（GPU單元名稱(chēng)和最大吞吐量的百分比），以及TEX和L2命中率。

我們知道，頂級(jí)的SOL GPU單元正在限制正在研究的工作負(fù)載的性能，因?yàn)檫@些單元正在運(yùn)行最接近其最大吞吐量的單元。我們現(xiàn)在需要了解什么是限制這些top-SOL單元的性能。

6.1。如果頂部SOL％為低

如上面第5.2.2節(jié)所述，有多種可能的原因。我們經(jīng)常將這些稱(chēng)為病理 - 并且與現(xiàn)實(shí)生活中的患者一樣，工作負(fù)荷可能同時(shí)遭受多種病癥的影響。我們首先檢查以下指標(biāo)的值：“GPU空閑％”和“SM單元活動(dòng)百分比”。

6.1.1。“GPU空閑％”度量標(biāo)準(zhǔn)

Range Profiler的“GPU Idle％”度量標(biāo)準(zhǔn)映射到“gr__idle_pct”P(pán)erfWorks度量標(biāo)準(zhǔn)。它是當(dāng)前工作負(fù)載下整個(gè)圖形和計(jì)算硬件管道閑置的GPU經(jīng)過(guò)周期的百分比。這些“GPU空閑”周期是CPU無(wú)法為GPU提供足夠快的命令的周期，因此GPU管線完全是空的，無(wú)需處理任何工作。請(qǐng)注意，Wait For Idle命令導(dǎo)致的管道排空不計(jì)為“GPU空閑”。

如果針對(duì)任何給定的GPU工作負(fù)載看到此度量標(biāo)準(zhǔn)大于1％，那么您知道此工作負(fù)載由于某種原因受CPU限制，并且此CPU工作負(fù)載的性能影響至少為1％。在這種情況下，我們建議測(cè)量以下CPU調(diào)用花費(fèi)的每個(gè)工作負(fù)載的總CPU時(shí)間，然后嘗試最小化最昂貴的CPU時(shí)間：

對(duì)于DX11：

• 沖洗{，1}

• 地圖

• UpdateSubresource {，1}

對(duì)于DX12：

• 等待

• ExecuteCommandLists

對(duì)于DX11和DX12：

• 任何創(chuàng)建或釋放呼叫

DX11說(shuō)明：

• ID3D11DeviceContext :: Flush強(qiáng)制執(zhí)行命令緩沖區(qū)啟動(dòng)，這可能需要Flush（）調(diào)用在CPU上停止。

• 在連續(xù)幀中映射相同的分段資源時(shí)，在STAGING資源上調(diào)用ID3D11DeviceContext :: Map可能會(huì)導(dǎo)致CPU因資源爭(zhēng)用而停頓。在這種情況下，當(dāng)前幀中的Map調(diào)用必須在內(nèi)部等待，直到前一幀（使用相同的資源）在返回之前已經(jīng)被處理。

• 使用DX11_MAP_WRITE_DISCARD調(diào)用ID3D11DeviceContext :: Map可能會(huì)導(dǎo)致CPU由于驅(qū)動(dòng)程序用盡版本空間而停頓。這是因?yàn)槊看螆?zhí)行Map（WRITE_DISCARD）調(diào)用時(shí)，驅(qū)動(dòng)程序都會(huì)返回一個(gè)指向固定大小內(nèi)存池的新指針。如果驅(qū)動(dòng)程序用盡版本空間，Map調(diào)用將停止。

DX12注意事項(xiàng)：

• 每個(gè)ExecuteCommandLists（ECL）調(diào)用都有一些與之關(guān)聯(lián)的GPU空閑開(kāi)銷(xiāo)，用于啟動(dòng)新的命令緩沖區(qū)。因此，為了減少GPU空閑時(shí)間，我們建議將所有命令列表分配到盡可能少的ECL調(diào)用，除非您真的想要在幀中的某些點(diǎn)發(fā)生命令緩沖區(qū)啟動(dòng)（例如，為了減少VR應(yīng)用程序中的輸入延遲在飛行中有一個(gè)框架）。

• 當(dāng)應(yīng)用程序調(diào)用ID3D12CommandQueue :: Wait時(shí)，操作系統(tǒng)（Windows 10）將暫停向該命令隊(duì)列的GPU提交新的命令緩沖區(qū)，直到等待調(diào)用返回。

注意：每個(gè)API調(diào)用的CPU時(shí)間可以使用Nsight通過(guò)捕獲一個(gè)幀，然后進(jìn)入Visual Studio - > Nsight - > Windows - > Events來(lái)測(cè)量：

6.1.2。“SM單元有效百分比”指標(biāo)

“SM單元活躍％”度量標(biāo)準(zhǔn)報(bào)告每個(gè)SM實(shí)例至少有1個(gè)warp（32個(gè)線程）活動(dòng)周期的百分比，在所有SM實(shí)例中平均。請(qǐng)注意，正在等待內(nèi)存請(qǐng)求返回的變形會(huì)被記錄為“正在運(yùn)行”/正在飛行中。

在Nsight：Visual Studio Edition 5.5中，此度量標(biāo)準(zhǔn)顯示在“管道總覽匯總”中的“范圍分析器結(jié)果”中。

對(duì)于全屏四元組或計(jì)算著色器工作負(fù)載，SM應(yīng)該在超過(guò)95％的工作負(fù)載中處于活動(dòng)狀態(tài)。如果不是，那么很可能SM之間存在不平衡，一些SM處于空閑狀態(tài)（沒(méi)有活動(dòng)的翹曲），而其他SM處于活動(dòng)狀態(tài)（至少有一個(gè)活動(dòng)翹曲）。運(yùn)行具有非均勻扭曲延遲的著色器時(shí)會(huì)發(fā)生這種情況。此外，具有少量小線程組的序列化調(diào)度調(diào)用不能足夠?qū)捯蕴畛銰PU上的所有SM。

如果對(duì)于任何幾何渲染工作負(fù)載，SM活動(dòng)百分比低于95％，您知道通過(guò)將異步計(jì)算工作與它重疊，可以在此工作負(fù)載上獲得性能提升。在DX12和Vulkan上，這可以通過(guò)使用Compute-only隊(duì)列來(lái)完成。請(qǐng)注意，即使SM活動(dòng)百分比接近100％，也可以從異步計(jì)算獲得加速，因?yàn)镾M可能被跟蹤為活動(dòng)狀態(tài)，但可能能夠承受更多活動(dòng)狀態(tài)。

對(duì)于任何工作負(fù)載而言，“SM單元活動(dòng)百分比”可能低于95％的另一個(gè)原因是頻繁的GPU管線消耗（等待空閑命令，又名WFI），這可能是由以下原因造成的：

• • 問(wèn)題：出于著色器調(diào)度原因，HS和DS處于活動(dòng)狀態(tài)時(shí)進(jìn)行很多狀態(tài)更改會(huì)導(dǎo)致SM消失。

  • 解決方案：盡量減少具有細(xì)化著色器的工作負(fù)載中的狀態(tài)更改（包括資源綁定）的數(shù)量。

  • 問(wèn)題：給定隊(duì)列上每批次的背靠背ResourceBarrier調(diào)用可能導(dǎo)致該隊(duì)列上的所有GPU工作都耗盡。

  • 解決方案：為了最大限度地減少ResourceBarrier調(diào)用的性能影響，重要的是盡量減少執(zhí)行ResourceBarrier調(diào)用的幀中的位置數(shù)量。

  • 問(wèn)題：默認(rèn)情況下，具有綁定無(wú)人機(jī)的后續(xù)渲染調(diào)用通常由我們的驅(qū)動(dòng)程序注入的GPU WFI命令進(jìn)行保守分隔，以防止任何數(shù)據(jù)危害。

  • 解決方案：可以使用以下調(diào)用來(lái)禁用無(wú)人機(jī)相關(guān)的等待空閑命令的插入：NvAPI_D3D11_ {Begin，End} UAVOverlap或NvAPI_D3D11_BeginUAVOverlapEx。

  • 請(qǐng)注意，在DX12，OpenGL和Vulkan中，無(wú)人機(jī)相關(guān)的等待空閑命令由應(yīng)用程序使用API調(diào)用（ResourceBarrier，glMemoryBarrier或vkCmdPipelineBarrier）顯式控制。

  • 問(wèn)題：在同一硬件隊(duì)列中的Draw和Dispatch調(diào)用之間切換會(huì)導(dǎo)致GPU WFI執(zhí)行。此外，在僅計(jì)算工作負(fù)載中執(zhí)行非CS狀態(tài)設(shè)置調(diào)用（例如，映射綁定到CS和圖形著色器階段的常量緩沖區(qū)）可能會(huì)導(dǎo)致WFI執(zhí)行。

  • 解決方案：批處理所有計(jì)算工作，并且不交叉圖形和計(jì)算API調(diào)用，包括Map（WRITE_DISCARD）調(diào)用在所有著色器階段綁定的“粘性”資源上。

  • 頻繁計(jì)算< - >圖形開(kāi)關(guān)在同一個(gè)DX11上下文中或在同一個(gè)DX12隊(duì)列中。

  • 在DX11上，多個(gè)渲染調(diào)用具有相同的無(wú)人機(jī)界限，并且沒(méi)有提供給我們驅(qū)動(dòng)程序的“無(wú)人機(jī)重疊”提示。

  • 在DX12上，ResourceBarrier在障礙之間幾乎沒(méi)有任何工作。

  • 數(shù)百在使用鑲嵌著色器/或幾何著色器的工作負(fù)載狀態(tài)的變化（除了硫苷被創(chuàng)建作為直通快速硫苷，使用NVAPI為DX11和DX12，或NV_geometry_shader_passthrough為GL）。

6.2。如果頂部SOL單位是SM

如果SM是最高SOL單位（或者以SOL％計(jì)），我們將分析Nsight Range Profiler中“SM問(wèn)題利用率”指標(biāo)的值。

SM單元是一個(gè)復(fù)雜單元，包含多個(gè)子單元，每個(gè)子單元具有相關(guān)的SOL％度量。PerfWorks庫(kù)允許查詢(xún)這些SM子SOL％指標(biāo)之一：“sm__issue_active_per_elapsed_cycle_sol_pct”，該指標(biāo)在范圍分析器中名為“SM IssueUtilizing Per Eilpsed Cycle”中公開(kāi)。此度量是SM調(diào)度程序發(fā)出至少一條指令的已用周期的百分比。如果在給定的工作負(fù)載中，我們有“每個(gè)經(jīng)過(guò)周期的SM問(wèn)題利用率”==“SM SOL％”，那么我們知道最高SM子限制器是SM指令調(diào)度器，即工作負(fù)載是SM問(wèn)題有限。

Range Profiler還在名稱(chēng)“SM Issue Utilization Per Active Cycle”中公開(kāi)“sm__issue_active_per_active_cycle_sol_pct”度量標(biāo)準(zhǔn)。與以前的度量唯一的區(qū)別在于，每個(gè)活動(dòng)周期1通過(guò)SM活動(dòng)周期數(shù)（具有至少一個(gè)活動(dòng)激活的周期）而不是經(jīng)過(guò)的周期（掛鐘）進(jìn)行標(biāo)準(zhǔn)化。

“每個(gè)活動(dòng)周期的SM問(wèn)題利用率”度量標(biāo)準(zhǔn)對(duì)于確定給定的工作負(fù)載是否部分受“SM占用率”（“sm__active_warps_avg_per_active_cycle”P(pán)erfWorks度量標(biāo)準(zhǔn)）限制很有用。

案例1：“每個(gè)活動(dòng)周期的SM問(wèn)題利用率”> 80％

如果SM是最高的SOL單位，并且“每個(gè)活動(dòng)周期的SM問(wèn)題利用率”大于80％，那么當(dāng)前工作負(fù)載主要受SM調(diào)度程序問(wèn)題率的限制，因此增加SM占用率不會(huì)顯著提高性能（在工作量最少不超過(guò)5％）。

在這種情況下，性能分類(lèi)過(guò)程的下一步是計(jì)算出哪些指令正在使SM調(diào)度器的帶寬飽和。通常，這是數(shù)學(xué)指令（FP32或整數(shù)操作數(shù)），但也可以是內(nèi)存指令，如紋理提取或共享內(nèi)存訪問(wèn)。此外，TEX指令（SRV和UAV訪問(wèn)）不太可能限制SM作為頂級(jí)SOL單元和SM問(wèn)題利用率> 80％的工作負(fù)載的性能，除非TEX單元的SOL％值也接近于SM。

案例2：“每個(gè)活動(dòng)周期的SM問(wèn)題利用率”<60％

如本次GTC2013會(huì)議幻燈片15（t = 14分鐘）所述，當(dāng)給定的warp指令不能發(fā)出時(shí)（因?yàn)樗牟僮鲾?shù)沒(méi)有準(zhǔn)備好或者因?yàn)樗枰獔?zhí)行的流水線子單元沒(méi)有準(zhǔn)備好 - 我們呼叫這是一個(gè)扭曲失速），那么SM指令調(diào)度器會(huì)嘗試通過(guò)切換到不同的主動(dòng)變形來(lái)隱藏延遲。因此，有兩種方法可以幫助SM調(diào)度程序?yàn)槊總€(gè)SM活動(dòng)周期發(fā)出更多指令：

1. 增加SM占用率（調(diào)度程序可以切換到的活動(dòng)warp的數(shù)量）和

2. 減少SM發(fā)布延遲時(shí)間（所以經(jīng)線保持停滯狀態(tài)的周期更少）。

方法1：增加SM入住率

如果SM是最高SOL單位（或關(guān)閉），“SM SOL％”<80％，并且“?每次活動(dòng)周期的SM問(wèn)題利用率”<60％，則增加SM入住率應(yīng)該可以提高性能。

為了增加SM占用率，首先必須弄清楚限制它的因素。

像素和計(jì)算著色器最常見(jiàn)的SM占用限制器是著色器使用的每個(gè)線程的硬件寄存器數(shù)量。

硬件寄存器計(jì)數(shù)對(duì)最大理論占用率（每個(gè)活動(dòng)周期的活動(dòng)變形數(shù)）的影響可在我們的CUDA占用率計(jì)算器中找到。以下是“計(jì)算能力”6.1的理論占有率圖，其中包括所有的GeForce GTX 10XX和Quadro Pxxxx GPU（GP10X）：

圖6.“計(jì)算能力”的CUDA占用計(jì)算器圖表6.1。

除寄存器外，以下資源還可限制Maxwell，Pascal和Volta GPU上的SM占用率：

• 對(duì)于圖形著色器：

  • 頂點(diǎn)著色器輸出屬性的總大小。

  • 像素著色器輸入屬性的總大小。

  • HS，DS或GS的輸入和輸出屬性的總大小。

  • 對(duì)于像素著色器，像素扭曲的亂序完成（通常由于諸如動(dòng)態(tài)循環(huán)或早退出分支的動(dòng)態(tài)控制流）。請(qǐng)注意CS沒(méi)有這個(gè)問(wèn)題，因?yàn)镃S線程組可以按任意順序完成。請(qǐng)參閱我們GDC 2016演講Gareth Thomas＆Alex Dunn的“Practical DirectX 12”演講幻燈片。

• 對(duì)于計(jì)算著色器：

  • 線程組大小可以直接影響SM占用率，因?yàn)榫€程組的線程組以全部或全部方式在SM上啟動(dòng)（即，線程組的所有線程都具有必需的資源并將一起啟動(dòng)，或者不會(huì)啟動(dòng)將）。線程組大小越大，像共享內(nèi)存和寄存器文件這樣的資源量化越粗糙。雖然有些算法可能真的需要大型線程組，但在所有其他情況下，開(kāi)發(fā)人員應(yīng)盡量將線程組大小限制為64或32個(gè)線程。這是因?yàn)?4或32線程的線程組為我們的著色器編譯器提供了最大的靈活性，為著色器程序選擇最佳可能的寄存器目標(biāo)。

  • 此外，對(duì)于具有高寄存器使用率（> = 64）以及SM（Group H MemoryLarrierWithGroupSync（）中的高線程組屏障停頓時(shí)間的著色器，將線程組大小降低為32可能會(huì)產(chǎn)生加速比，與64相比較。 > = 64寄存器指導(dǎo)可確保每個(gè)SM限制的32個(gè)最大線程組（CUDA占用率計(jì)算器中與架構(gòu)相關(guān)的“線程塊/多處理器”限制）不會(huì)成為SM主要占用限制器。

  • 每個(gè)線程組分配的共享內(nèi)存字節(jié)總數(shù)也可以直接影響SM占用率，這可以通過(guò)將各種數(shù)字插入CUDA占用率計(jì)算器中看出。

我們關(guān)于實(shí)現(xiàn)占用率的CUDA Nsight文檔頁(yè)面包括計(jì)算著色器的一些額外可能的SM占用限制器：

• 線程組內(nèi)的工作負(fù)載不平衡。

• 啟動(dòng)的線程組太少。這對(duì)于圖形著色器來(lái)說(shuō)也是一個(gè)問(wèn)題，它沒(méi)有啟動(dòng)足夠的warps來(lái)完全占用GPU Wait For Id之間的SM。

注意：實(shí)際上有兩種方法可以減少線程組大?。?/span>

• 方法1：將線程組大小降低N倍，同時(shí)將網(wǎng)格發(fā)射維度增加N.參見(jiàn)上文。

• 方法2：將N> = 2個(gè)線程的工作合并到一個(gè)線程中。這允許通過(guò)寄存器在N個(gè)合并線程之間共享公共數(shù)據(jù)，或者在寄存器中執(zhí)行減少操作，而不是使用原子操作符（例如HLSL中的InterlockedMin）在共享內(nèi)存中執(zhí)行減少操作。此外，這種方法還具有在N個(gè)合并線程中自動(dòng)分?jǐn)偩€程組統(tǒng)一操作的優(yōu)點(diǎn)。但是，應(yīng)該警惕這種方法可能導(dǎo)致登記數(shù)量膨脹。

注意：如果您想了解某個(gè)給定工作負(fù)載的SM占用量是否主要針對(duì)某個(gè)全屏Pixel Shader或某個(gè)計(jì)算著色器的寄存器數(shù)限制，則可以執(zhí)行以下操作：

• 在Scrubber中添加...“程序范圍”，并找到您有興趣研究的著色器程序范圍。右鍵單擊您的程序范圍，啟動(dòng)Range Profiler并檢查管道總覽摘要中的“SM占用率”值。

• 點(diǎn)擊Scrubber中的“Time（ms）”行，在Range中選擇一些渲染調(diào)用。將選項(xiàng)卡切換到API檢查器，選擇占用工作負(fù)載（PS或CS）中大部分周期的著色器階段，然后單擊著色器名稱(chēng)旁邊的“統(tǒng)計(jì)”鏈接。

• 這會(huì)打開(kāi)“Shaders”Nsight窗口（見(jiàn)下面的屏幕截圖），其中顯示了著色器的硬件寄存器數(shù)量，在“Regs”列中。請(qǐng)注意，您可能需要等待幾秒鐘才能填充著色器統(tǒng)計(jì)信息。

• 使用圖6中的CUDA占用率計(jì)算器圖查找與此寄存器計(jì)數(shù)相關(guān)的最大理論占用率，并將其與該范圍分析器為該著色器報(bào)告的實(shí)際“SM占用率”進(jìn)行比較。

• 如果實(shí)現(xiàn)的占用率遠(yuǎn)低于最大占用率，那么您知道SM占用率受限于每個(gè)線程的寄存器數(shù)量以外的其他因素。

圖7. Nsight的“Shaders View”，顯示“Regs”列中每個(gè)著色器的硬件寄存器數(shù)量。

為了減少為給定著色器分配的寄存器總數(shù)，可以查看DX著色器組件并研究著色器每個(gè)分支中使用的寄存器數(shù)量。硬件需要為最需要寄存器的分支分配寄存器，并且跳過(guò)該分支的經(jīng)線以不理想的SM占用情況運(yùn)行。

對(duì)于全屏通道（像素或計(jì)算著色器），解決此問(wèn)題的典型方法是運(yùn)行預(yù)處理，將像素分為不同的區(qū)域，并針對(duì)每個(gè)區(qū)域運(yùn)行不同的著色器置換：

• 對(duì)于計(jì)算著色器，此SIGGRAPH 2016演示文稿介紹了一種使用DispatchIndirect調(diào)用將專(zhuān)用計(jì)算著色器應(yīng)用于屏幕上不同圖塊的解決方案，每個(gè)著色器排列使用可變數(shù)量的線程塊：“Uncharted 4中的延遲照明” - Ramy El Garawany（淘氣狗）。

• 對(duì)于像素著色器，可以使用不同的專(zhuān)業(yè)化方法：全屏模板緩沖區(qū)可以在預(yù)處理中填充以對(duì)像素進(jìn)行分類(lèi)。然后，通過(guò)在像素著色器執(zhí)行之前（這應(yīng)該由我們的驅(qū)動(dòng)程序自動(dòng)完成）依靠模板測(cè)試來(lái)發(fā)生多個(gè)繪制調(diào)用，并且使用模板測(cè)試來(lái)丟棄當(dāng)前著色器置換沒(méi)有的像素觸摸。此GDC 2013演示文稿使用此方法優(yōu)化MSAA延遲渲染：“孤島危機(jī)3渲染技術(shù)” - Tiago Sousa，Carsten Wenzel，Chris Raine（Crytek）。

最后，為了更好地理解給定計(jì)算著色器的SM占用限制，您可以使用我們的CUDA占位計(jì)算器電子表格。要使用它，只需填寫(xiě)GPU的CUDA計(jì)算能力以及著色器的資源使用情況（線程組大小，來(lái)自Shader視圖的寄存器計(jì)數(shù)以及共享內(nèi)存大小（以字節(jié)為單位））。

方法2：減少SM失步延遲

除了增加SM占用率外，還有另一種方法可以增加SM問(wèn)題利用率：通過(guò)減少SM發(fā)布 - 停止周期的數(shù)量。這些是指令執(zhí)行周期之間的SM活動(dòng)周期，在此期間，由于其操作數(shù)未準(zhǔn)備就緒或由于數(shù)據(jù)路徑上的資源爭(zhēng)用而導(dǎo)致該指令需要在其上執(zhí)行，因此warp指令被暫停。

如果所有著色器都在做數(shù)學(xué)運(yùn)算和紋理提取，并且每個(gè)活動(dòng)周期的SM問(wèn)題利用率很低，那么可以合理地假設(shè)大多數(shù)停頓周期都來(lái)自于紋理提取結(jié)果的依賴(lài)關(guān)系，我們經(jīng)常稱(chēng)為“紋理延遲”。在這種情況下：

1. 如果著色器包含一個(gè)可以在著色器編譯時(shí)可以知道迭代次數(shù)的循環(huán)（可能通過(guò)每個(gè)循環(huán)次數(shù)使用不同的著色器置換），那么嘗試強(qiáng)制FXC通過(guò)使用循環(huán)中的[unroll]循環(huán)屬性來(lái)完全展開(kāi)循環(huán)HLSL。

2. 如果著色器正在執(zhí)行無(wú)法完全展開(kāi)的動(dòng)態(tài)循環(huán)（例如光線循環(huán)循環(huán)），請(qǐng)嘗試對(duì)紋理獲取指令進(jìn)行批處理，以減少TEX依賴(lài)性延遲的數(shù)量（通過(guò)將獨(dú)立紋理拾取分批次編組為2到4在HLSL層面的背靠背說(shuō)明）。
   請(qǐng)參閱“優(yōu)化光線行進(jìn)循環(huán)”附錄。

3. 如果著色器對(duì)給定紋理的每個(gè)像素的所有MSAA子采樣進(jìn)行迭代，則可以在該紋理的單個(gè)TEX批處理指令中一起提取所有子采樣。由于MSAA子采樣在DRAM中彼此相鄰存儲(chǔ)，因此將它們一起提取可以最大化TEX命中率。

4. 如果紋理加載是基于條件的，那么大多數(shù)時(shí)間都是真實(shí)的（例如，如果（idx

5. 嘗試通過(guò)改進(jìn)TEX和L2緩存命中率來(lái)減少TEX延遲。通過(guò)調(diào)整采樣模式以使相鄰像素/線程獲取更多相鄰紋理像素，通過(guò)使用mipmap（如果適用）以及通過(guò)減小紋理尺寸和使用更緊湊的紋理格式，可以提高TEX＆L2命中率。

6. 嘗試減少執(zhí)行的TEX指令的數(shù)量（可能使用每個(gè)紋理指令使用分支，將其編譯為T(mén)EX指令謂詞，請(qǐng)參閱FXAA 3.11 HLSL的示例，例如：“if（！doneN）lumaEndN = FxaaLuma（...）;”） 。

案例3：[60,80]中的問(wèn)題利用率％

在這種情況下，我們遵循案例1（高問(wèn)題利用率）和案例2（低問(wèn)題利用率）的方法。

6.3。如果頂部SOL單元不是SM

6.3.1。如果頂層SOL單元是TEX，L2或DRAM

如果頂層SOL單元不是SM，而是其中一個(gè)內(nèi)存子系統(tǒng)單元（TEX-L1，L2和DRAM），則可能導(dǎo)致性能較差的根本原因是TEX或L2緩存抖動(dòng)-GPU友好的訪問(wèn)模式（通常，在一個(gè)warp中相鄰的線程訪問(wèn)相距甚遠(yuǎn)的內(nèi)存）。在這種情況下，頂部限制單元可能是TEX或L2，但根本原因可能在SM執(zhí)行的著色器中，所以使用第6.2節(jié)中的方法（如果頂部SOL單元是SM ）。

如果頂級(jí)SOL單元是DRAM，并且其SOL％值不差（> 60％），那么這個(gè)工作負(fù)載是DRAM吞吐量受限的，并且將其與另一個(gè)通道合并應(yīng)該加速該幀。一個(gè)典型的例子是將伽馬校正通道與另一個(gè)后處理通道合并。

6.3.2。如果頂部SOL單位是CROP或ZROP

如果CROP是頂級(jí)SOL單元，則可以嘗試使用較小的渲染目標(biāo)格式（例如R11G11B10F而不是RGBA16F），并且如果使用多個(gè)渲染目標(biāo)，則可以嘗試減少渲染目標(biāo)的數(shù)量。此外，更積極地殺死像素著色器中的像素可能是值得的（例如，對(duì)于某些透明效果，丟棄具有小于1％不透明度的像素）。查看此博客文章，獲取優(yōu)化透明度渲染的更多可能策略：“透明度（或半透明度）渲染”。

如果ZROP是頂層SOL單元，則可以嘗試使用較小的深度格式（例如D16代替D24X8用于陰影貼圖，或用D24S8代替D32S8），以及以前后順序繪制不透明物體，以便ZCULL （粗粒度深度測(cè)試）有機(jī)會(huì)在調(diào)用ZROP和像素著色器之前丟棄更多的像素。

6.3.3。如果頂部SOL單位是IA

如前所述，IA會(huì)執(zhí)行索引緩沖區(qū)和頂點(diǎn)緩沖區(qū)加載，以收集頂點(diǎn)著色器的輸入頂點(diǎn)。如果IA是頂級(jí)SOL單元，則可以嘗試使用16位索引緩沖區(qū)而不是32位索引緩沖區(qū)。如果這不會(huì)增加IA SOL％，則可以嘗試優(yōu)化頂點(diǎn)重用和局部性的幾何圖形。此外，從其余屬性中分離出位置流對(duì)于z-only或陰影貼圖渲染可能是有益的。

概要

為了結(jié)束，我們的SOL引導(dǎo)式性能分類(lèi)方法針對(duì)任何給定的GPU工作負(fù)載執(zhí)行以下操作：

• 檢查“SOL SOL％”值（5.2節(jié)和5.3節(jié)）。

  • 如果> 80％=>（A）嘗試從頂層SOL單元中取出工件（見(jiàn)第5.2.1節(jié)）。

  • 如果<60％=>（B）嘗試增加SOL％（5.2.2和6.1節(jié)）。

  • （A）和（B）都可以。

• 如果SM是最高SOL單位（或以SOL％計(jì)）或“SM SOL％”低于80％：

  • 如果> 80％=>（C）嘗試機(jī)會(huì)性地跳過(guò)指令組或考慮將某些計(jì)算移動(dòng)到查找表（見(jiàn)第6.2.1節(jié)）。

  • 如果<60％=>（D）嘗試增加SM占有率（飛行中活動(dòng)的經(jīng)紗數(shù)量）并減少SM發(fā)貨 - 停止周期的數(shù)量（見(jiàn)第6.2.2節(jié)）。

  • 其他人同時(shí)做（C）和（D）。

  • 檢查“每個(gè)活動(dòng)周期的SM問(wèn)題利用率”值。

• 如果其他單位是頂級(jí)SOL單位，請(qǐng)嘗試減少發(fā)送到該單位的工作量。（見(jiàn)第6.3節(jié)）。

要使用此方法，您只需要安裝Nsight：在PC上安裝Visual Studio Edition 5.5以及安裝最新的可用圖形驅(qū)動(dòng)程序。

附錄：性能分類(lèi)示例

示例1：TEX-Interface有限的工作負(fù)載

在GTX 1060 6GB @ 1506 Mhz上運(yùn)行的HBAO +“DrawBlurXPS”全屏像素著色器工作負(fù)載在Nsight Range Profiler中具有以下指標(biāo)：

• 頂部SOLs：SM：94.5％|TEX：94.5％|L2：37.2％|DRAM：27.6％

• GPU空閑：0.0％=>不受CPU限制（參見(jiàn)第6.1.1節(jié)）

• SM單元有效：99.5％=>無(wú)SM閑置問(wèn)題（參見(jiàn)第6.1.2節(jié)）

• SM問(wèn)題使用率每循環(huán)周期：47.2％

• 每個(gè)活動(dòng)周期的SM問(wèn)題利用率：47.5％

• SM占用：每個(gè)活動(dòng)周期62.2個(gè)活動(dòng)的經(jīng)紗

• TEX命中率：88.9％

• 二級(jí)命中率：87.3％

分析：

• 由于SM SOL％和TEX SOL％都非常接近（實(shí)際上相等），所以我們知道工作負(fù)載受到SM和TEX單元之間接口吞吐量的限制。

• 由于SM和TEX SOL％很高（94.5％），我們知道工作負(fù)載完全受SM和TEX單位的吞吐量的限制（95％與SOL％值一樣高）。

• 由于每個(gè)活動(dòng)周期的SM問(wèn)題利用率遠(yuǎn)低于80％，我們知道指令調(diào)度器的帶寬遠(yuǎn)未達(dá)到飽和。因此，增加SM占用率（每個(gè)活動(dòng)周期的活動(dòng)經(jīng)紗數(shù)量）可能有助于理論上的幫助。但是由于SM SOL％（94.5％）太高，我們知道增加入住率并不會(huì)顯著提高績(jī)效。

• TEX和L2的命中率很好（接近90％）。

結(jié)論：這個(gè)工作負(fù)載主要受SM-TEX接口帶寬的限制，唯一可以顯著加快執(zhí)行速度的方法是減少執(zhí)行的TEX指令的數(shù)量（例如，通過(guò)使用收集指令在一個(gè)TEX中執(zhí)行4個(gè)單通道負(fù)載指令，或通過(guò)計(jì)算每個(gè)線程的多個(gè)輸出值并通過(guò)寄存器共享紋理采樣）。

示例2：數(shù)學(xué)有限的工作負(fù)載

HBAO +“DrawCoarseAOPS”工作負(fù)載在GTX 1060 @ 1506 Mhz上的Range Profiler中具有以下指標(biāo)：

• 頂部SOLs：SM：93.4％|TEX：71.9％|L2：50.1％|DRAM：27.3％|CROP：3.6％

• GPU空閑：0.0％=>不受CPU限制（請(qǐng)參閱第6.1.1節(jié)）

• SM單元激活：99.5％=>沒(méi)有SM空閑問(wèn)題（參見(jiàn)章節(jié)6.1.2）

• 每個(gè)周期的SM問(wèn)題利用率：93.4％

• 每個(gè)活動(dòng)周期的SM問(wèn)題利用率：95.9％

頂部SOL分析：

• 最上面的SOL單元是SM，它的最大吞吐量為93.4％，輔助SOL單元（TEX，L2和DRAM）比SM SOL多20％，所以我們知道工作負(fù)載主要是SM通過(guò)限制。

• 第二個(gè)上限是TEX單位，以最大吞吐量的71.9％運(yùn)行。

現(xiàn)在，讓我們進(jìn)行以下思考實(shí)驗(yàn)：如果此GPU中的TEX單元以某種方式無(wú)限快速完成，則工作負(fù)載仍將受到SM SM內(nèi)93％SM內(nèi)發(fā)生的工作的限制。這些工作中的一部分通常是來(lái)自著色器的紋理提取，因此如果TEX單元無(wú)限快地完成并且SM最初受TEX延遲限制，SM SOL可能會(huì)增加。但是，由于95％的價(jià)值與實(shí)踐中的SOL％值一樣高，我們知道SM SOL％無(wú)法通過(guò)使其他單位更快（或處理更少的工作）而顯著增加，因此我們知道唯一的顯著加速這一工作量的方法是找出SM內(nèi)部的性能限制器。

附加分析：

1. 由于SM是最大限制因素，并且“每次經(jīng)過(guò)周期的SM問(wèn)題利用率”==“SM SOL％”，因此我們知道此工作負(fù)載的最大SM子SOL度量標(biāo)準(zhǔn)為SM問(wèn)題利用率％，即工作負(fù)載為主要受指令發(fā)行率的限制。

2. 由于“每次活動(dòng)周期的SM問(wèn)題利用率”> 80％，我們知道工作負(fù)載不受SM占用率的明顯限制，也就是說(shuō)，增加每個(gè)活動(dòng)周期的活動(dòng)warps數(shù)量并不會(huì)顯著提高性能。

3. 我們可以推斷，性能不受紋理獲取指令的延遲的限制，否則我們將“SM活動(dòng)周期的利用率”遠(yuǎn)低于80％。

4. 我們可以推斷性能不受TEX單元的限制，否則我們會(huì)讓TEX SOL％值更接近SM SOL％值。

結(jié)論：這個(gè)工作負(fù)載主要受著色器中數(shù)學(xué)指令的數(shù)量（FP32操作數(shù)和/或整數(shù)操作數(shù)和/或其他數(shù)學(xué)操作如rsqrt，pow，cos / sin等）的限制。為了加快速度，人們需要找到一種方法來(lái)以某種方式遮蔽較少的像素，或者每像素執(zhí)行較少的數(shù)學(xué)指令。

示例3：TEX-Latency有限的工作負(fù)載

現(xiàn)在，我們來(lái)看看https://github.com/NVIDIAGameWorks/D3DSamples中的“Advanced Motion Blur”DX11 SDK示例

默認(rèn)情況下，應(yīng)用程序以720p窗口模式運(yùn)行。為了使它以4K全屏模式啟動(dòng)，我在main.cpp中進(jìn)行了以下編輯：

#if0deviceParams.startfull-screen=false;deviceParams.backBufferWidth=1280;deviceParams.backBufferHeight=720;＃其他deviceParams.startfull-screen=true;deviceParams.backBufferWidth=3840;deviceParams.backBufferHeight=2160;＃萬(wàn)一

接下來(lái)，我們可以在main.cpp中手動(dòng)插入一個(gè)工作負(fù)載標(biāo)記，它將被NSight攔截并在Range Profiler中成為“Perf Marker”范圍：

如果（g_view_mode==VIEW_MODE_FINAL）{D3DPERF_BeginEvent（0x0，L“FinalPass”）;//...ctx->Draw（6，0）;D3DPERF_EndEvent（）;}

最后，我們可以按照第4節(jié)中的步驟使用Nsight Range Profiler來(lái)分析此工作負(fù)載。在GTX 1060 @ 1506 Mhz上，Range Profiler提供以下指標(biāo)：

• 頂部SOLs：SM：40.7％|TEX：39.8％|L2：36.3％|作物：26.4％|DRAM：25.7％

• GPU已用時(shí)間：0.70毫秒

• GPU空閑：0.2％=>不受CPU限制（請(qǐng)參閱第6.1.1節(jié)）

• SM單元有效：97.4％=>無(wú)SM閑置問(wèn)題（請(qǐng)參閱第6.1.2節(jié)）

• SM問(wèn)題利用率每循環(huán)周期：40.7％

• 每個(gè)活動(dòng)周期的SM問(wèn)題利用率：41.8％

• SM占用：每個(gè)活動(dòng)周期37.0個(gè)活動(dòng)經(jīng)紗

• TEX命中率：80.1％

• 二級(jí)命中率：83.0％

分析：

• 頂級(jí)SOL％單位是SM和TEX。

• 最高的SOL％值低于60％，所以此工作負(fù)載在GPU上運(yùn)行效率低下。

• 由于“每個(gè)活動(dòng)周期的SM問(wèn)題利用率”遠(yuǎn)低于80％，并且TEX SOL％非常接近SM SOL％，所以工作負(fù)載受TEX延遲限制。

• 由于頂級(jí)SOL單位是SM，“SM SOL％”<80％和“每個(gè)活動(dòng)周期的SM問(wèn)題利用率”<60％（請(qǐng)參見(jiàn)第6.2.2節(jié)），因此工作負(fù)載也受SM占用限制。

• TEX和L2命中率很好。

實(shí)驗(yàn)：刪除提前退出

根據(jù)第6.2.2節(jié)，我們知道，對(duì)于SM作為頂級(jí)SOL單元的工作負(fù)載，“SM SOL％”<80％和“每次活動(dòng)周期的SM問(wèn)題利用率”<60％，性能可能受到以下限制：

• 由于沒(méi)有足夠的指令級(jí)并行性來(lái)隱藏指令等待時(shí)間，所以出現(xiàn)高的問(wèn)題延遲時(shí)間和/或

• SM入住率低（由于沒(méi)有足夠的活躍經(jīng)線來(lái)隱藏問(wèn)題攤位）。

讓我們首先找出低SM占用率的主要原因。我們知道這個(gè)像素著色器有一個(gè)提前退出分支，如果分支被采用，通過(guò)輸出調(diào)試顏色，我們可以看到大多數(shù)像素正在提前退出。我們也從第6.2.2節(jié)知道，亂序像素著色器翹曲完成（與其啟動(dòng)順序相比）可以限制SM占用。

為了驗(yàn)證早退出分支實(shí)際上限制了占用率，讓我們做一下簡(jiǎn)單地將它從像素著色器（ps_gather.hlsl）中移除的實(shí)驗(yàn)：

#if0//如果速度太短，我們只顯示顏色紋理并退出如果（TempNX
度量新的價(jià)值舊價(jià)值新舊GPU已用時(shí)間5.05毫秒0.70毫秒7.21x頂部SOL [0]SM：47.2％SM：40.7％1.16x頂部SOL [1]TEX：39.2％TEX：39.8％0.01XSM單元激活99.9％97.4％1.03X每個(gè)經(jīng)過(guò)周期的SM問(wèn)題利用率47.2％40.7％1.16x每個(gè)活動(dòng)周期的SM問(wèn)題利用率47.2％41.8％1.13xSM入住率62.037.01.68xTEX命中率85.8％80.1％1.07倍L2命中率95.2％83.0％1.15倍
表1.刪除了早期退出分支的新度量標(biāo)準(zhǔn)。
我們發(fā)現(xiàn)新的工作負(fù)載仍然受到SM占用的限制，但占用率（62.0）達(dá)到了硬件限制（64.0） - 即使在這種最大占用率的情況下，我們也看到工作負(fù)載仍然受TEX頂級(jí)SOL單元的TEX延遲限制SM和TEX。
顯然，由于取消了提前退出，工作量減慢了7倍，但這是可以的，因?yàn)槲覀兿Ｍ赃@種方式研究其性能限制器。這實(shí)際上是我們經(jīng)常用來(lái)分析工作負(fù)載的一種方法，我們預(yù)計(jì)會(huì)出現(xiàn)多個(gè)性能問(wèn)題：如果最初的問(wèn)題太復(fù)雜，且SOL％s較低的根本原因不明確，則我們簡(jiǎn)化問(wèn)題（在此情況下，消除低占用率的預(yù)期根本原因），并對(duì)簡(jiǎn)單問(wèn)題重新進(jìn)行分析，直到頂層SOL％s變好。這實(shí)際上是一個(gè)分而治之的性能調(diào)試方法。通過(guò)采取醫(yī)學(xué)比喻，我們正在消除一種病理學(xué)，以便對(duì)其他病理學(xué)的分析更清楚并且沒(méi)有“相聲”。
注意：對(duì)于簡(jiǎn)化的問(wèn)題，性能優(yōu)化可能無(wú)法加速原始問(wèn)題。但我們認(rèn)為，即使發(fā)生這種情況，對(duì)大多數(shù)情況下簡(jiǎn)單問(wèn)題的分析仍然非常值得，因?yàn)檫@不僅有助于我們驗(yàn)證我們對(duì)性能問(wèn)題的理解是否正確，而且還有助于重新設(shè)計(jì)用于避免GPU性能低效的渲染算法。
結(jié)論：
此工作負(fù)載中SM占用率較差的主要原因是像素著色器提前退出。將這個(gè)像素著色器移動(dòng)到計(jì)算著色器可以緩解這個(gè)問(wèn)題（扭曲完成比給定線程組中的其他處理器更早完成將仍然限制SM占用），但是也會(huì)增加一些開(kāi)銷(xiāo)，用于通過(guò)無(wú)人機(jī)寫(xiě)入指令寫(xiě)出結(jié)果。
或者，使用第6.2.2節(jié)中描述的模板掩模方法在這種情況下也應(yīng)該有所幫助，因?yàn)樗鼘⑹谷料袼刂鲀H處理復(fù)雜像素，并且所有這些像素將按照啟動(dòng)順序完成。
優(yōu)化1：使用R11G11B10F而不是RGBA16F
原始SDK示例應(yīng)用程序使用RGBA16F紋理格式存儲(chǔ)HDR顏色，這些顏色是由Motion Blur“Final Pass”過(guò)濾的顏色。
因?yàn)檫@個(gè)RGBA16F紋理的alpha通道從來(lái)沒(méi)有被這個(gè)應(yīng)用程序?qū)嶋H使用過(guò)，所以我們可以將其更改為更緊湊的R11G11B10F格式，從而生成在這種情況下看起來(lái)相同的輸出圖像。實(shí)現(xiàn)這種優(yōu)化只是main.cpp中的格式更改：
CreateTextureWithViews（設(shè)備，surface_desc->寬度，surface_desc->高度，#if0DXGI_FORMAT_R16G16B16A16_FLOAT，DXGI_FORMAT_R16G16B16A16_FLOAT，DXGI_FORMAT_R16G16B16A16_FLOAT，＃其他DXGI_FORMAT_R11G11B10_FLOAT，DXGI_FORMAT_R11G11B10_FLOAT，DXGI_FORMAT_R11G11B10_FLOAT，＃萬(wàn)一

	這樣做可以通過(guò)提高TEX命中率來(lái)幫助減少顏色提取的TEX延遲：
度量新的價(jià)值舊值新舊GPU已用時(shí)間4.25毫秒5.05毫秒增加19％頂部SOL [0]SM：63.7％SM：47.2％1.35x頂部SOL [1]TEX：52.9％TEX：39.2％1.35xSM單元激活99.9％99.9％1.00倍每個(gè)經(jīng)過(guò)周期的SM問(wèn)題利用率63.7％47.2％1.35x每個(gè)活動(dòng)周期的SM問(wèn)題利用率63.8％47.2％1.35xSM入住率62.862.01.01xTEX命中率94.2％85.8％1.10xL2命中率91.5％95.2％0.96x

	表2.顏色格式從RGBA16F降至R11G11B10F的新指標(biāo)。


	優(yōu)化2：循環(huán)展開(kāi)

	現(xiàn)在，讓我們來(lái)看看這個(gè)全屏像素著色器的HLSL。它包含以下循環(huán)，每個(gè)循環(huán)迭代有3個(gè)紋理提取，以及一個(gè)跳過(guò)循環(huán)體的動(dòng)態(tài)分支，用于某個(gè)循環(huán)迭代索引：
for（inti=0;i
使用以下命令行通過(guò)FXC運(yùn)行此HLSL：
fxc/Tps_5_0/Ges/O3ps_gather.hlsl

	...在DXASM中產(chǎn)生以下控制流和紋理提?。?/span>
循環(huán)itofr5.w，r4.wger6.x，r5.w，cb0[21].zbreakc_nzr6.xieqr6.x，r3.x，r4.wif_nzr6.xmovr4.w，r3.w繼續(xù)endif...sample_l_indexable（texture2d）（float，float，float，float）r6.zw，r6.xyxx，t2.zwxy，s1，l（0.000000）...
sample_l_indexable（texture2d）（float，float，float，float）r6.w，r6.xyxx，t1.yzwx，s1，l（0.000000）...
sample_l_indexable（texture2d）（float，float，float，float）r6.xyz，r6.xyxx，t0.xyzw，s2，l（0.000000）madr5.xyz，r5.wwww，r6.xyzx，r5.xyzxiaddr4.w，r4.w，l（1）ENDLOOP

	我們知道這個(gè)工作量部分是TEX延遲有限。發(fā)生這種情況的原因是紋理提取和從屬數(shù)學(xué)指令之間沒(méi)有足夠的指令。為了讓我們的著色器編譯器更好地調(diào)度紋理指令，這個(gè)循環(huán)需要展開(kāi)，所以我們的編譯器知道所有的紋理拾取都將被執(zhí)行，并且可以決定如何調(diào)度它們（可能將多個(gè)紋理拾取組合在一起）嘗試最佳用獨(dú)立的數(shù)學(xué)指令覆蓋紋理指令的延遲。

	在這種情況下，循環(huán)迭代次數(shù)（“c_S”）必須在FXC編譯時(shí)已知，而原始著色器中c_S是常量緩沖區(qū)值時(shí)不是這種情況。

	“c_s”常量存儲(chǔ)在一個(gè)常量緩沖區(qū)中，但由于該值不會(huì)逐幀變化，因此可以為不同的c_s常量生成此像素著色器的排列，或者僅使用#define對(duì)該值進(jìn)行硬編碼， 喜歡這個(gè)：
#if0floatc_S;＃其他#definec_S15floatc_S_unused;＃萬(wàn)一

	現(xiàn)在c_S在FXC編譯時(shí)已知，for（）循環(huán)可以使用[unroll] HLSL關(guān)鍵字完全展開(kāi)，如下所示：
[unroll]for（inti=0;i度量新的價(jià)值舊值新舊GPU已用時(shí)間3.44毫秒4.25毫秒24％的收益頂部SOL [0]SM：81.2％SM：63.7％1.27倍頂部SOL [1]TEX：81.2％TEX：52.9％1.53xSM單元激活99.9％99.9％1.00倍每個(gè)經(jīng)過(guò)周期的SM問(wèn)題利用率74.4％63.7％1.17x每個(gè)活動(dòng)周期的SM問(wèn)題利用率74.5％63.8％1.17xSM入住率45.262.80.72xTEX命中率96.2％94.2％1.02XL2命中率85.6％91.5％0.94倍
表3.使用展開(kāi)循環(huán)的新度量標(biāo)準(zhǔn)。
由于寄存器壓力增加，SM占用從每個(gè)活動(dòng)周期的62.8到45.2有效彎曲下降：完全展開(kāi)該循環(huán)導(dǎo)致更多的TEX指令同時(shí)執(zhí)行，這會(huì)消耗更多寄存器來(lái)存儲(chǔ)TEX結(jié)果。盡管如此，“每次活動(dòng)周期的SM問(wèn)題利用率”指標(biāo)為74.5％，接近80％，因此有更多的主動(dòng)式經(jīng)紗可能會(huì)稍微提高性能，但不會(huì)超過(guò)工作負(fù)荷的10％。
總體而言，兩項(xiàng)優(yōu)化相結(jié)合，使工作負(fù)載的性能提高了47％（5.05至3.44毫秒）。并且，為了記錄，在退出早期退出分支后，這些優(yōu)化會(huì)使工作負(fù)載（0.75到0.62 ms）獲得21％的增益。
附錄：優(yōu)化Ray-Marching循環(huán)
如第6.2.2節(jié)所述（“減少SM問(wèn)題 - 延遲延遲”），包含TEX指令的動(dòng)態(tài)循環(huán)可能受到TEX指令的延遲以及沒(méi)有可以從相同的計(jì)劃調(diào)度的獨(dú)立指令的限制warp（沒(méi)有指令級(jí)并行性），并且SM中的活動(dòng)warps數(shù)量不足以完全隱藏TEX延遲。
這種情況通常發(fā)生在光線漫游動(dòng)態(tài)循環(huán)中，這些循環(huán)通常用于屏幕空間反射（SSR）著色器以及光線行進(jìn)的體積照明。
在HLSL中，具有提前退出的典型SSR光線前進(jìn)循環(huán)如下所示：
floatMinHitT=1.0;floatRayT=Jitter*Step+Step;
[loop]for（inti=0;i
通過(guò)部分展開(kāi)循環(huán)2次并將紋理獲取指令背靠背放置在HLSL中，獨(dú)立紋理指令的批次可以并行執(zhí)行，并且第二次獲取的延遲可以部分由延遲隱藏的第一個(gè)。
假設(shè)NumSteps是2的倍數(shù)，那么生成的HLSL看起來(lái)像這樣：
floatMinHitT=1.0;floatRayT=Jitter*Step+Step;[loop]for（inti=0;i
通過(guò)在1607 Mhz的GTX 1080上以4K為單位的SSR測(cè)試應(yīng)用程序進(jìn)行上述優(yōu)化，SSR工作負(fù)載所用的GPU時(shí)間從0.54 ms變?yōu)?.42 ms（工作負(fù)載加速29％）。通過(guò)進(jìn)一步批量處理4個(gè)紋理，而不是2個(gè)，GPU時(shí)間下降到0.33 ms（工作負(fù)載加速64％：0.54 - > 0.33 ms /幀）。