共用方式為

分析 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 效能分析器 (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」 變數。

按一下 [開始] 按鈕，然後輸入 「系統變數」。 系統屬性視窗隨即開啟。 按一下 [編輯系統內容變數]。 從 [系統屬性] 對話方塊中選取 [環境變數]。 「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 佇列代表排入硬體的圖形工作負載，但不一定由硬體處理。 開啟追蹤檔案時，會顯示在追蹤取得時間之間記錄的所有事件。 若要計算啟動時間，請選取感興趣的區域，並放大第一個內容 CPU 佇列的初始部分， (這是使用 Ctrl +Z 顯示活動) 。 More information about GPUView Controls can be found in the GPUView Help file section "Summary of GPUView Controls". 下圖只會顯示GeometryRealization.exe進程放大至內容 CPU 佇列的第一個部分。 內容 CPU 佇列的色彩是由佇列正下方的矩形表示，而佇列中的相同色彩資料封包會顯示硬體上排入佇列的 GPU 工作。 內容佇列中的影線模式封包會顯示目前的封包，這表示應用程式希望硬體在螢幕上呈現內容。

    顯示「內容 C P U 佇列」範例的螢幕擷取畫面。

  3. 啟動時間是 app 第一次啟動 (在此案例中，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 同步處理資訊。 持續放大，直到清楚看到一個 vsync 值得注意的資料為止。 藍色線條是 v 同步時間的位置。 這些通常會每 16 毫秒 (60 fps) 發生一次，但如果 DWM 遇到效能問題，則會執行速度變慢，因此每 32 毫秒 (30 fps) 發生一次。 若要瞭解時間，請從一個藍色列選取下一個藍色列，然後查看 GPUView 視窗右下角所報告的 ms 數目。

    顯示 v 同步時間範例的螢幕擷取畫面。

  5. 若要測量每個畫面的 CPU 時間，請測量轉譯所涉及的所有線程所花費的時間長度。 從效能觀點來看，可能值得縮小預期最相關的執行緒。 例如，在幾何實現範例中，內容會以動畫顯示，而且必須在畫面上呈現每個畫面，讓 UI 執行緒成為重要的畫面。 一旦您判斷要查看哪一個執行緒，請測量此執行緒上的橫條長度。 其中一些平均會產生每個畫面的 CPU 時間。 下圖顯示 UI 執行緒上所花費的時間。 它也顯示這次適合兩個連續的 v 同步處理，這表示達到 60FPS。

    顯示 U I 執行緒所花費時間的螢幕擷取畫面。

    您也可以查看對應時間範圍的翻轉佇列以確認 DWM 能夠呈現每個畫面。

    顯示 「翻轉佇列」範例的螢幕擷取畫面。

  6. GPU 時間的測量方式與 CPU 時間相同。 放大相關區域，如同測量 CPU 時間的情況。 使用與內容 CPU 佇列色彩相同的色彩，測量 GPU 硬體佇列中橫條的長度。 只要橫條符合連續的 v 同步處理，應用程式就會在 60FPS 順利執行。

    顯示「GPU 硬體佇列」範例的螢幕擷取畫面，其中顯示應用程式在 60 F P S 上執行的資訊。

計算呈現 8192 基本類型時所呈現的 CPU 和 GPU 時間

  1. 如果您再次遵循相同的步驟，追蹤會顯示一個畫面格的所有 CPU 工作不符合一個 v 同步處理和下一個畫面。 這表示應用程式已系結 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 時間能夠容納在兩個連續的 v 同步處理內。 在圖形的稍後部分，這不是 true。

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

gpuview 螢幕擷取畫面。

摘要

GPUView和XPerf和功能強大的工具來分析DirectX應用程式的效能。 本文是使用這些工具和瞭解基本效能測量和應用程式特性的入門。 除了瞭解工具的使用方式之外，必須先瞭解要分析的應用程式。 從尋找問題解答開始，例如應用程式嘗試達到什麼目標？ 系統中哪些執行緒最重要？ 您願意做出哪些取捨？ 分析效能追蹤時，請先查看明顯的問題位置。 應用程式 CPU 或 GPU 是否系結？ 應用程式是否能夠呈現每個畫面？ 搭配瞭解應用程式的工具，可以提供非常實用的資訊，讓您瞭解、尋找效能問題，最後解決效能問題。