跳轉到主要內容
PIX 能夠在 XBOX Series X|S GPU 擷取中檢視 GPU 上波與指令的執行情況。在預設配置中,Shader Trace 檢視位於 Tools 索引標籤上。

設定

您可以從檢視頂端的工具列開啟 Options 面板來設定追蹤。您可以選取要追蹤的全域 ID,以及其他各種選項。設定好追蹤後,按一下工具列中的 “Generate Trace” 按鈕即可產生追蹤。 單一追蹤可以擷取一個著色器引擎的波以及一個 SIMD 的指令。您可以在 Options 面板中設定要追蹤的 SIMD。

波與指令

產生追蹤後,您會看到在所追蹤 SIMD 上執行的波。若要檢視在所選著色器引擎上執行的所有波,請在 Options 面板中切換 “All Waves”。 檢視所追蹤 SIMD 的波時,檢視會自動調整以容納檢視中的波數目。若要將波鎖定在原位,使其不會隨著檢視重新縮放而移動,請在 Options 面板中切換 “Fixed Lane Count”。 當您按一下所追蹤 SIMD 中的波時,檢視會切換為顯示單一波及其指令。Trace Tokens 與 Shader Stats 面板會變成可見。Trace Tokens 面板會顯示硬體在波執行時擷取的權杖,每個執行的指令一個項目。如果在 Options 面板中啟用 “Other SIMD”,這也會包含與所追蹤 SIMD 共用紋理單元之 SIMD 的權杖,有助於了解共用資源的使用率。Shader Stats 面板會依指令在著色器二進位檔中出現的順序顯示每個指令的統計資料。您可以在所選的波與所追蹤 SIMD 上所選著色器的所有波之間切換此檢視。

著色器統計資料

根據切換選項,著色器統計資料代表所選的波,或所追蹤 SIMD 上所選著色器的所有波。
  • Issue Count:指令發出的平均次數。
  • Arbitration Stall Count:指令發生仲裁停滯的平均次數。
  • Arbitration Stall Cost:波已就緒但無法發出指令的平均 SCLK 數。如需詳細資訊,請參閱下方關於停滯的章節。
  • Total Stall Cost:此次發出與同一個波上前一次發出之間的平均 SCLK 數。
  • Issue Gap:此指令與同一個波上前一個指令之間的平均 SCLK 數。
  • Issue Cost:發出指令的平均 SCLK 數。
  • % of Total:指令的成本相對於所有指令成本的比例。總成本 = 發出間隙 + 停滯成本 + 發出成本
  • % of Longest:指令的成本相對於成本最高之指令的比例。
  • % Visited:至少發出過一次該指令的波百分比。

轉譯

指令密集的追蹤可能會對時間軸的轉譯效能造成負擔。如果發生這種問題,您可以使用 Options 面板中的 “Instructions” 臨界值,設定繪製指令的時間範圍精細度。

了解使用率

您可以從 Options 面板新增其他時間軸通道:“Utilization” 與 “Perf Counters”。 使用率通道會顯示硬體平行功能單元的使用情況:VMEM (紋理與 LDS)、VALU、純量 (SALU 與 SMEM) 以及分支/訊息。另外也有匯出與閒置的通道。每個單元一次可以發出一個指令。例外是立即指令 (以 IMMED 權杖表示),它們由每個波在內部執行,不使用 ALU 或執行路徑。每個波都可以同時執行這些指令。 其他使用率通道也從指令資料衍生而來,以顯示匯出停滯與仲裁停滯等實用資訊。 效能計數器會擷取幾個主要著色器引擎匯流排上的匯流排活動。這些計數器有助於提供整體效能的檢視,並協助找出瓶頸,例如 SPI 波建立速度、匯出匯流排使用量等。計數器代表在取樣期間匯流排處於作用中的週期數。

架構概觀

XBOX Series X|S 著色器架構以工作群組處理器 (WGP) 為基礎,WGP 會在一組工作項目上執行著色器程式。一個 WGP 由 4 個 SIMD32、兩條紋理記憶體路徑與一個著色器記憶體 (LDS) 組成。SIMD32 是向量 ALU 以及向量 GPR。每個 WGP 也包含一個純量快取 (SQC),其中同時包含指令快取與純量資料快取。

純量與向量 ALU

純量與向量 ALU 的相似之處在於,它們都會發出指令並將其放入 FIFO。接著指令會透過讀取 GPR 或轉送先前指令的結果來收集其運算元。當所有運算元都可用時,指令即可執行。 由於與其他指令競爭 GPR 讀取,發出與執行之間的時間是可變的。若要追蹤執行延遲,請在 Options 面板中切換 “Exec Latency”。此選項需要重新追蹤才能收集資料。當您選取波時,Trace Tokens 面板會顯示每個指令的執行延遲。 向量 ALU 有兩條平行執行管線:一般 FMA 與超越函數。每個時脈只會發出一個指令,但兩條管道可以同時執行。超越函數管道最多每 4 個時脈只能接受一個新指令。

紋理記憶體與 LDS

一對中的兩個 SIMD32 都會選擇要發出 VMEM 指令 (紋理或 LDS) 的波,並將該指令傳送到中央仲裁器。此仲裁器會在兩個 SIMD 之間,以及在 LDS 與紋理之間進行選擇。 這會讓指令實際傳送到執行單元 (紋理定址器或 LDS) 的時間產生不確定性。若要追蹤執行延遲,請在 Options 面板中切換 “Exec Latency”。此選項需要重新追蹤才能收集資料。當您選取波時,Trace Tokens 面板會顯示每個指令的執行延遲。 這提供了共用 VMEM 匯流排上活動的完整樣貌。4 種類型的指令會各自保持順序:Simd0 LDS、SIMD0 TA、SIMD1 LDS、SIMD1 TA。

LDS-Direct 與向量內插

使用 LDS-Direct 的 VALU 指令 (包括 VINTERP 指令) 會在發出之前被指令仲裁器延遲約 5 個週期。此延遲會在追蹤中顯示。在波發出 LDS_direct/vinterp 指令之後,該波要經過約 5 個週期的延遲才能發出一般類型的 VALU 指令。在此期間,其他波可以發出 VALU 運算。

匯出與 SX 配置

匯出是指將資料從 VGPR 移至 SX (匯出緩衝區) 的過程。對於像素著色器,這會針對色彩與深度資料進行;對於頂點著色器,則會針對位置與參數資料進行。此路徑也用於將資料傳送至 GDS。 像素或頂點著色器在匯出之前,必須先在 SX 的緩衝區中配置空間。如果波在收到配置之前嘗試發出匯出指令,它會休眠直到配置發生為止。與先前的架構不同,這裡沒有「提早配置」(在波開始時就進行配置)。所有配置都在波執行期間進行。 與其他指令不同,匯出分為兩部分進行,並在著色器追蹤中分別回報。發出指令時,這實際上是匯出發生的要求,而不是匯出本身。這在追蹤中以 EXPREQ_GFX 或 EXPREQ_GDS 權杖表示。所有 PS 與 VS 著色器匯出的一般匯出都使用 GFX 類型,而 GDS 則有自己的類型。匯出要求可以是每個執行緒多個 DWORD。稍後,匯出要求會被授與,而這才是實際從 VGPR 讀取資料並將其傳輸到輸出緩衝區的動作。這在追蹤中以 EXPGNT_PAR_COL 或 EXPGNT_POS_GDS 權杖表示。 對於像素著色器,EXPGNT_PAR_COL 表示這是色彩或深度匯出,而 EXPGNT_POS_GDS 表示這是 GDS 匯出。對於頂點著色器,EXPGNT_PAR_COL 表示這是參數匯出,而 EXPGNT_POS_GDS 表示這是位置匯出或 GDS 作業。

分支

分支以 BRANCH_TAKEN 權杖表示。BRANCH_NOT_TAKEN 表示在該次指令執行中未採用分支。 如果指令在迴圈中執行,同一個分支指令可能會在追蹤中出現多次。有時可能是 BRANCH_TAKEN,有時可能是 BRANCH_NOT_TAKEN。

停滯

匯出停滯

當波正在等待發出匯出指令時,就會被視為匯出停滯。這是從前一個指令發出到發出匯出要求之間的時間。匯出停滯會在使用率通道中依著色器階段視覺化。匯出可能會在等待匯出緩衝區空間時停滯。您可以在 Trace Tokens 面板中搜尋 EXPORT_ALLOC 權杖,查看波何時已在匯出緩衝區中配置空間。

仲裁停滯

對於每個已準備好發出的波,仲裁器會為每種類型挑選一個波發出一個指令:VMEM (紋理與 LDS)、VALU、純量 (SALU 與 SMEM) 以及分支/訊息。這些類型對應於著色器追蹤檢視中的使用率通道,另外還新增了一個匯出通道。對於任何指令類型,仲裁器都有可能不選擇任何波發出。如果執行已經積壓並忙於處理先前的指令,就可能發生這種情況。 如果波已準備好發出指令但未被仲裁器選中,該波就會停滯。READY 權杖會插入在波已就緒但未執行的第一個 SCLK。從那時起到波下一個發出的指令之間的任何 SCLK 都被視為停滯。 如果波沒有有效的指令、正在等待相依性停滯清除、正在等待多週期指令完成,或正在等待 s_waitcnt、s_sleep 或 s_nop,則該波不會處於就緒狀態。 如果波已就緒,它就有有效的指令,並且可能贏得仲裁 (以已發出的指令表示) 或輸掉仲裁 (其他波贏得或沒有波贏得)。如果接收單元的 FIFO 已滿 (SIMD、TA、LDS、匯出要求 RAM)、仲裁器鎖定在某個子句中而只有該波能贏得,或仲裁器正在等待多週期記憶體指令發出 (請查看前一個指令),波就可能輸掉仲裁。 仲裁停滯會在使用率通道中依指令類別視覺化。每個指令的 Arbitration Stall Cost 可以在 Shader Stats 面板中查看。它是指令 Total Stall Cost 的子集。

多週期指令發出

某些指令的發出時間長度不固定。發出每個指令所需的 SCLK 數會顯示在 Trace Tokens 面板的 “Issue” 欄中。時間軸上指令的寬度也取決於發出該指令所需的 SCLK 數。

常見模式

VALU「瀑布」

VALU 瀑布模式的影像 當許多波已準備好發出 VALU 指令,但因為每個時脈只能發出一個 VALU 指令而輸掉仲裁時,就會出現 VALU「瀑布」模式。 仲裁器有規則決定在任何特定時間哪個波具有優先權,但一般而言,在數千個時脈的期間內是相當公平的。這可能會造成間隙,讓波積壓等待其他波發出其 VALU 指令。
最後修改於 2026年10月8日