共用方式為

分析 DirectX 應用程式

這說明如何使用隨附於 Windows Performance Toolkit 一部分的 XPerf 和 GPUView 工具，測量 DirectX 應用程式的一些最重要的效能時間測量。 這不是瞭解工具的完整指南，而是用來分析 DirectX 應用程式效能的特定適用性。 雖然這裡討論的大部分技術都與所有 DirectX 應用程式相關，但它與使用交換鏈結的應用程式最相關，而不是使用 SIS/VSIS 和 XAML 動畫之 XAML 所建置的 DirectX 應用程式。 我們會逐步引導您完成關鍵效能時間測量、如何取得和安裝工具，並採用效能測量追蹤，然後分析它們以瞭解應用程式瓶頸。

關於工具

XPerf

XPerf 是一組以 Windows 事件追蹤 （ETW） 為基礎的效能分析工具，專為測量和分析詳細的系統和應用程式效能和資源使用量而設計。 從 Windows 8 開始，這個命令行工具具有圖形使用者介面，稱為 Windows Performance Recorder （WPR） 和 Windows Performance Analyzer （WPA）。 如需這些工具的詳細資訊，請參閱 Windows Performance Toolkit （WPT）： Windows Performance Toolkit網頁。

ETW 會收集要求的核心事件，並將其儲存到稱為事件追蹤記錄檔 （ETL） 檔案的檔案中。 這些核心事件提供有關執行應用程式時應用程式和系統特性的詳細資訊。 藉由啟用追蹤擷取、執行需要分析的應用程式場景、停止擷取，將數據儲存在 ETL 檔案中。 接著，您可以使用命令行工具 xperf.exe 或可視化追蹤分析工具，xperfview.exe來分析相同或不同計算機上的檔案。

GPUView

GPUView 是用來判斷圖形處理器 （GPU） 和 CPU 效能的開發工具。 它會查看直接記憶體存取 （DMA） 緩衝區處理和視訊硬體上所有其他視訊處理的效能。

對於高度依賴 GPU 的 DirectX 應用程式，GPUView 是一個功能強大的工具，可瞭解 CPU 與 GPU 上完成的工作之間的關聯性。 如需 GPUView的詳細資訊，請參閱 GPUView。

與 XPerf類似，ETW 追蹤會先透過啟動追蹤服務、執行需要考慮之應用程式分析的案例、停止服務，並將資訊儲存在 ETL 檔案中。 GPUView 以圖形化格式呈現 ETL 檔案中的數據。

安裝 GPUView 工具後，我們建議您閱讀「GPUView 說明」功能表中的「GPUView的主要顯示」主題。 其中包含如何解譯 GPUView UI 的實用資訊。

安裝工具

XPerf 和 GPUView 都包含在 Windows Performance Toolkit （WPT） 中。

XPerf 隨附於適用於 Windows 的 Windows 軟體開發工具包 （SDK） 中。 下載 Windows SDK。

GPUView 可在 Windows 評定與部署套件 （Windows ADK） 中使用。 下載 Windows ADK。

安裝之後，您必須將包含 XPerf 和 GPUView 的目錄新增至系統“Path”變數。

按兩下 [開始] 按鈕，然後輸入 「系統變數」。 [系統屬性] 視窗隨即開啟。 按兩下 [編輯系統環境變數]。 從 [系統屬性] 對話框中選取 [環境變數]。 「路徑」變數位於 「系統變數」底下。 將包含 xperf.exe 和 GPUView.exe 的目錄附加至路徑。 這些可執行檔位於 「Windows Kits」 內的 「Windows Performance Toolkit」 目錄中。 預設位置為：C：\Program Files （x86）\Windows Kits\10\Windows Performance Toolkit。

效能時間度量

大部分的應用程式預期會順利執行，並回應使用者輸入。 不過，視您想要的案例而定，效能的一個層面可能比另一個層面更重要。 例如，對於在觸控平板電腦上執行的新聞閱讀程式應用程式，最重要的層面是一次檢視單一文章，並流覽/縮放/卷動相同或不同的文章。 在此情境中，不需要每幀渲染所有內容。 不過，在觸控手勢上順利捲動文章的能力非常重要。

在另一個情況下，若遊戲或影片轉譯應用程式掉幀，則使用大量動畫時會出現問題。 在此情況下，在不中斷使用者輸入的情況下，在畫面上呈現內容的能力非常重要。

為了瞭解應用程式的哪個部分有問題，第一個步驟是決定最重要的案例。 一旦了解應用程式的核心層面以及它們將如何運作，使用工具尋找疑難會變得更容易。

一些最常見的效能時間計量如下所示：

啟動時間

從進程啟動到第一次呈現於螢幕上的時間。 當系統暖和時，此量測比較有用，這表示在應用程式啟動數次之後會進行測量。

每個畫面的CPU時間

CPU 主動處理一個畫面的應用程式工作負載的時間。 如果應用程式順利執行，則一個畫面所需的所有處理都會在一個 v 同步間隔內發生。 以60Hz的螢幕刷新率，每幀時間相當於16毫秒。 如果 CPU 時間 / 框架大於 16 毫秒，可能需要 CPU 優化，才能產生無問題的應用程式體驗。

每個畫面的 GPU 時間

GPU 主動處理一個畫面的應用程式工作負載的時間。 若處理一個畫面的時間超過16毫秒，應用程式就會受限於GPU的效能。

能夠瞭解應用程式是 CPU 還是 GPU 系結，將會縮小程式代碼有問題的部分。

取得效能時間測量追蹤

執行下列步驟以追蹤：

  1. 以系統管理員身分開啟命令視窗。
  2. 如果應用程式已在執行中，請關閉它。
  3. 將目錄變更為 Windows Performance Toolkit 資料夾內的 gpuview 目錄。
  4. 輸入 「log.cmd」 以啟動事件追蹤。 此選項會記錄最有趣的事件。 其他可用的選項會記錄事件的不同範圍。 例如，"v" 或詳細日誌模式會擷取 GPUView 能捕捉到的所有事件。
  5. 啟動範例，並以涵蓋您需要分析之效能路徑的方式練習範例。
  6. 返回命令視窗，然後再次輸入 「log.cmd」，以停止記錄。
  7. 這會輸出 gpuview 資料夾中名為 “merged.etl” 的檔案。 您可以將此檔案儲存至另一個位置，而且您可以在相同或不同的計算機上進行分析。 若要檢視堆疊擷取詳細數據，請儲存與應用程式相關聯的符號檔 （.pdb）。

測量

注意

幾何實現範例的測量是在具有整合式 DirectX11 圖形卡的四核心計算機上進行。 測量會根據計算機組態而有所不同。

 

本節示範如何測量啟動時間、以及每帧的 CPU 和 GPU 時間。 您可以擷取計算機上相同範例的效能追蹤，並查看各種度量的差異。

若要分析 GPUView中的追蹤，請使用 GPUView.exe開啟 “merged.elt” 檔案。

啟動時間

啟動時間是由應用程式開始所花費的總時間來測量，直到內容第一次出現在畫面上為止。

最好遵循上一節所列的步驟，並採用這些變化來測量啟動時間：

  • 如果您在第一次啟動應用程式時進行啟動測量，則稱為冷啟動。 這可能會因您在一小段時間內啟動應用程式幾次之後所採取的度量而有所不同。 這稱為暖啟動。 根據應用程式在啟動時建立的資源數目，這兩個啟動時間之間可能會有很大的差異。 視應用程式目標而定，測量其中一個或另一個可能是理想的。
  • 當您記錄效能資訊時，只要畫面上顯示第一個畫面，就會終止應用程式。

使用 GPUView 計算啟動時間

  1. 在 GPUView中，向下捲動至相關程式，在此案例中 GeometryRealization.exe。

    顯示 GPUView 中進程範例的螢幕快照。

  2. 上下文 CPU 佇列代表圖形工作負載已排入硬體，但不一定正在被硬體處理。 開啟追蹤檔案時，它會顯示在擷取追蹤時記錄的所有事件。 若要計算啟動時間，請選取感興趣的區域，使用 Ctrl +Z 放大第一個內容 CPU 佇列的初始部分（這是顯示活動的區域）。 如需有關 GPUView 控件的更多資訊，請參閱 GPUView 說明檔中「GPUView 控件的摘要」一節。 下圖只顯示放大至內容 CPU 佇列第一個部分的 GeometryRealization.exe 程式。 上下文 CPU 佇列的顏色由佇列正下方的矩形所代表，佇列中相同顏色的資料包表示在硬體上排隊的 GPU 工作。 在內容佇列中的影線圖案封包顯示了當前的封包，這表示應用程式希望硬體將內容顯示在螢幕上。

    顯示「內容 C P U 佇列」範例的螢幕快照。

  3. 啟動時間是應用程式第一次啟動的時間（在此案例中為UI線程進入點模組 SHCORE.dll），直到內容第一次出現的時間（以影線封包標示）。 此處的圖強調感興趣的區域。

    注意

    實際的當前資訊在翻轉佇列中呈現，因此，時間會延長，直到當前的封包在翻轉佇列中實際完成為止。

     

    下圖中看不到完整的狀態列，也顯示醒目提示部分之間的經過時間。 這是應用程式的啟動時間。 在這種情況下，對於上述機器，結果大約是 240 毫秒。

    螢幕快照，其中顯示「內容 C P U 佇列」中有關啟動時間的相關區域。

每個畫面的CPU和 GPU 時間

測量 CPU 時間時有一些考慮事項。 尋找追蹤記錄中您已練習並需要分析的情境所在的區域。 例如，在幾何實現範例中，已分析的其中一個情境是從渲染 2048 個到 8192 個圖元之間的轉換，這些圖元都是未實現的（也就是說，幾何圖形不是每一幀都進行細分）。 追蹤清楚地顯示基本類型轉換前後CPU和 GPU 活動的差異。

正在分析兩個案例，以計算每個畫面的CPU和 GPU 時間。 如下所示。

  • 從渲染 2048 個未具現的基本元件過渡到 8192 個未具現的基本元件。
  • 從繪製 8192 個已實現的圖元到 8192 個未實現的圖元。

在這兩種情況下，觀察到幀速率大幅下降。 測量 CPU 和 GPU 時間、兩者之間的關聯性，以及追蹤中的一些其他模式，可以提供應用程式中有問題區域的相關實用資訊。

計算 2048 基本類型呈現未實現時的 CPU 和 GPU 時間

  1. 使用 GPUView.exe開啟追蹤檔案。

  2. 向下捲動至 GeometryRealization.exe 程序。

  3. 選取一個區域來計算CPU時間，並使用CTRL + Z 放大它。

    螢幕快照，顯示 [內容 CPU 佇列] 中選取用來計算 C P U 時間的區域。

  4. 切換 F8 來顯示 v 同步資訊。 持續放大，直到能輕鬆清楚地看到一個幀同步的數據量。 藍色線條是 v 同步時間的位置。 通常，這些會每 16 毫秒 （60 fps） 發生一次，但如果 DWM 遇到效能問題，就會變慢，因此每 32 毫秒 （30 fps） 就會發生一次。 若要了解時間，請從一個藍色列選取到下一個，然後查看 GPUView 視窗右下角報告的毫秒數。

    顯示 v 同步時間範例的螢幕快照。

  5. 若要測量每個畫面的CPU時間，請測量轉譯所涉及的所有線程所花費的時間長度。 從效能的觀點來看，縮小預期最相關的線程可能值得。 例如，在幾何實作範例中，內容以動畫顯示，並需要在每一個畫面渲染，使UI線程成為關鍵。 一旦您判斷要查看的線程，請測量此線程上橫條的長度。 通過計算這些的平均值，可以得出每幀的 CPU 時間。 下圖顯示UI線程上所花費的時間。 它還顯示，這次的時間符合兩次連續的垂直同步，這表示其達到了每秒60幀。

    顯示U I線程所花費時間的螢幕快照。

    您也可以藉由查看對應時間範圍的翻轉佇列來驗證，這顯示 DWM 能夠呈現每個畫面。

    顯示「翻轉佇列」範例的螢幕快照。

  6. GPU 時間可以用與 CPU 時間相同的方式來測量。 放大相關區域，如同測量CPU時間的情況。 使用與內容 CPU 佇列色彩相同的色彩，測量 GPU 硬體佇列中橫條的長度。 只要橫條圖表符合連續的垂直同步，應用程式就會以 60FPS 流暢運行。

    顯示「GPU 硬體佇列」範例的螢幕快照，顯示應用程式以每秒60幀運行的資訊。

計算 8192 個基元尚未實現時的 CPU 和 GPU 時間

  1. 如果您再次遵循相同的步驟，追蹤會顯示一幀的所有 CPU 工作無法在一個垂直同步與下一個垂直同步之間完成。 這表示應用程式已系結 CPU。 UI 線程正在讓 CPU 飽和。

    顯示UI執行緒使C P U飽和的範例螢幕快照。

    查看翻轉佇列時，也很清楚 DWM 無法呈現每個畫面。

    顯示 D W M 無法呈現每個畫面的範例螢幕快照。

  2. 若要分析時間花費在哪裡，請在 XPerf 中的 開啟追蹤。 若要在 XPerf中分析啟動時間，請先在 GPUView中尋找時間間隔。 將滑鼠停留在間隔的左邊和右側，並記下 GPUView 視窗底部顯示的絕對時間。 然後在 XPerf 中開啟相同的 .etl 檔案，然後向下捲動至 [CPU 取樣依據 CPU] 圖形，以滑鼠右鍵點擊並選取 [選取範圍...]。這可讓您輸入透過查看 GPU 追蹤發現的感興趣區間。

    螢幕快照，顯示 [Windows 效能分析] 中的 [C P U 按 C P U 進行取樣]。

  3. 移至 "追蹤" 功能表，並確定已勾選 "載入符號"。 此外，請移至 [追蹤 -> 設定符號路徑]，然後輸入應用程式符號路徑。 符號檔包含個別資料庫 （.pdb） 中已編譯可執行檔的偵錯資訊。 此檔案通常稱為 PDB。 如需符號檔的詳細資訊，請參閱這裡：符號檔。 此檔案可以位於應用程式目錄的 [偵錯] 資料夾中。

  4. 若要取得應用程式中所花費時間的明細，請以滑鼠右鍵按兩下上一個步驟中選取的間隔，然後按兩下 [摘要數據表]。 若要查看每個 dll 中花費多少時間，請從 [欄] 功能表取消選取 [堆疊]。 請注意，此處的 [計數] 數據行會顯示指定 dll/函式內的樣本數目。 由於每個毫秒大約會擷取一個樣本，因此此數位可作為每個 dll/函式花費多少時間的最佳猜測。 從 [資料行] 選單檢查 [堆疊] 會顯示呼叫圖表中每個函式所花費的包括時間。 這有助於進一步細分問題點。

  5. 2048 年未實現基本類型的堆疊追蹤資訊會顯示在幾何實現程式中花費 30% CPU 時間。 其中大約36個% 的時間是花費在幾何鑲嵌和划動。

  6. 8192 未實現基本類型的堆疊追蹤信息顯示，大約 60% 的 CPU 時間（4 個核心）用於幾何實現。

    顯示 C P U 時間堆疊追蹤資訊的螢幕快照。

計算正在實現 8192 基本類型時的 CPU 時間

從配置檔中清楚看出應用程式是CPU系結的。 為了減少 CPU 的運算時間，可以將幾何資訊建立一次並加以快取。 快取的內容可以轉譯每個畫面，而不會產生每個畫面的幾何鑲嵌成本。 在 GPUView 中查看應用程式已實現部分的追蹤時，顯然 DWM 能夠呈現所有畫面，且 CPU 時間已大幅減少。

顯示 GPUView 中追蹤範例的螢幕快照，其中顯示 D W M 能夠呈現每個幀。

圖表的第一個部分顯示已實現8192個基本類型。 每個畫面對應的 CPU 時間能夠在兩次連續的垂直同步之內完成。 在圖形的後段，這種情況並不成立。

在 XPerf中，CPU 閑置的時間最長，只有大約 25% CPU 時間花費在幾何實現應用程式上。

gpuview 螢幕快照。

總結

GPUView 以及 XPerf 是功能強大的工具，用來分析 DirectX 應用程式的效能。 本文是使用這些工具並瞭解基本效能測量和應用程式特性的入門。 除了瞭解工具的使用方式之外，首先請務必瞭解要分析的應用程式。 從尋找問題解答開始，例如應用程式嘗試達成什麼目標？ 系統中哪些線程最為重要？ 你願意做出什麼取捨？ 分析效能追蹤時，請從查看明顯的有問題的地方開始。 應用程式是受 CPU 或 GPU 限制嗎？ 應用程式是否能夠呈現每個畫面？ 工具與應用程式瞭解一起可提供非常實用的資訊，讓您了解、尋找並最終解決效能問題。

 

 

  • Last updated on