共用方式為

Windows 標題的常見問題

  • 發行項

Microsoft Windows Gaming 和 Graphics Technologies Developer Relations 群組每年會針對許多 Windows 遊戲執行效能分析。 在這些研討會期間，我們會獲得實際操作體驗，以結合我們每日收到的開發人員意見反應和查詢。 有時候，我們會協助追蹤標題中的問題當機或其他問題，讓我們進一步深入瞭解開發人員遇到的問題。

本文重點說明我們在目前世代電腦遊戲中看到的許多常見問題。

CPU-Limited效能

大部分的遊戲受限於高效能圖形處理單位系統上的 CPU 效能， (GPU) 。 這有時會因為對繪製提交進行批次處理而不佳，但更通常，這是因為其他遊戲系統耗用大量可用的 CPU 週期。 在少數情況下，我們已將 GPU 視為限制，原因是高填滿率或圖元著色器需求、高解析度設定或視訊卡的低頂點著色器效能。

因為大部分的標題都受限於 CPU，所以最大的效能勝出來自優化 CPU 密集的遊戲系統。 一般而言，AI 或物理系統與相關聯的衝突偵測邏輯是 MICROSOFT Direct3D 應用程式中 CPU 週期的主要取用者。 改善這些系統的任何工作都可以改善遊戲的整體效能。

批次管理不佳

使用 GPU 達到良好的平行處理原則時，需要繪製批次包含足夠的幾何，而且著色器具有正確的複雜度，讓視訊卡保持忙碌，而不要使用太多批次，命令緩衝區就會滿溢。 在目前的世代硬體上，我們建議每個畫面的繪製批次提交約 300 或更少， (較低的效能 CPU) ，以防止驅動程式處理命令緩衝區成為效能瓶頸。 某些其他 API 狀態呼叫和驅動程式組合可能會導致成本高昂的 CPU 處理 (驅動程式編譯著色器，例如) ，因此強烈建議進行例行效能分析。

過多的記憶體複製

在開發大部分的電腦標題期間，開發人員會使用方便的資料結構和字串來管理內容。 字串比較、複製和其他操作所需的 CPU 工作通常具有可測量的額外負荷，特別是在考慮與快取和記憶體子系統相關聯的效能點擊時。 一旦產品進入主要測試和發行階段，就應該在開發這些系統以移除或最小化對字串處理的依賴時進行計畫。

過度使用動態繪製提交

新式視訊硬體在處理靜態資料時效能良好。 高階介面卡通常具有非常大量的視訊記憶體，但動態資料無法有效地利用此記憶體。

雖然動態頂點緩衝區/索引緩衝區的合理使用模式可以針對動態內容實作，但許多標題會過度使用此慣用語，以用於其他靜態內容。 我們最常看到使用二進位空間分割 (BSP) 樹狀結構與入口網站型系統，這些系統會將幾何儲存在未對應至硬體的資料結構中，而且必須處理成每個框架的緩衝區。 盡可能將更多內容放入靜態資源，可以大幅降低將資料傳輸至視訊卡的頻寬額外負荷、更妥善地使用內建 VRAM，並降低處理此內容所涉及的 CPU/快取額外負荷。

檔案處理的高額外負荷

相較于具有嚴格載入時間需求的主控台標題，電腦遊戲獲得長時間載入時間的信譽。 我們分析許多標題使用檔案子系統的方式，會顯示一些常見問題。

開啟檔案的額外負荷通常高於開發人員預期。 隨著隨選病毒掃描器廣泛使用，以及 NTFS 的額外功能，開啟檔案是相當昂貴的作業。 一次開啟許多檔案或重複開啟和關閉相同的檔案，因此處理檔案管理的不佳方法。 有些遊戲已嘗試先測試檔案是否存在，再開啟檔案，以降低此效能成本。 事實上，在 NTFS 上測試檔案是否存在需要開啟檔案，因此在開啟前進行測試會產生兩次費用。

允許附加元件修改或模式的遊戲，或仍然包含開發 Scaffolding 來檢查覆寫資料檔案的遊戲，可能會因為檢查這些檔案而造成大量延遲載入遊戲，即使這些檔案不存在也一樣。 我們建議只有在使用特殊命令列參數或其他模式指標執行時，遊戲才會檢查這些檔案，因此只有使用這些功能的使用者才會實際支付這些 (通常大量) 檢查的效能成本。

您可以透過下列命令，從檔案系統取得其他效能：

  • 適當地使用檔案系統提示FILE_FLAG_RANDOM_ACCESS和FILE_FLAG_SEQUENTIAL_SCAN
  • 調整大小緩衝區以避免大量呼叫 OS 的讀取/寫入 API
  • 以非同步方式存取檔案
  • 在背景載入執行緒

我們也強烈建議在建置或安裝時間 (離線轉換資料) ，而不是在第一次執行遊戲時依賴轉換，因為這麼做會對每個使用者造成顯著的效能稅。

緩慢和令人沮喪的安裝

我們所看到的另一個常見問題是許多新式電腦遊戲需要很長的安裝時間。 安裝程式會多次提示使用者，有時只是告訴使用者「您不需要安裝 DirectX」。一般而言，這些違規安裝程式需要使用者選取 [ 下一步 ] 或 [ 確定 ] 多次，然後才實際開始安裝遊戲。 一旦開始，我們就會看到一些標題需要一小時以上的時間，使用者才能有機會進行遊戲。 我們很強烈地認為遊戲體驗的第一小時不應該是安裝。

建議您使用許多方法來處理安裝。 首先，讓提示保持簡單且最少。 其次，建構您的遊戲資料，讓部分或所有資料檔都可以直接從散發磁片使用， 新式 DVD 磁片磁碟機具有非常高的頻寬。 第三，請考慮在標題中實作隨選安裝，以減少或消除安裝程式，並讓使用者儘快進入遊戲。 (如需隨選安裝的詳細資訊，請參閱 Install-on-Demand for Games.)

如需遊戲安裝的詳細資訊，請參閱 簡化遊戲安裝。

缺少實體記憶體的考慮

由於市場電腦硬體的廣泛變化，標題通常會使用臨機操作組態測試來選取圖形化詳細資料層級的預設設定。 我們所看到的部分標題在這些測試中使用視訊記憶體大小，但無法將此與實體記憶體大小相互關聯。 為了處理遺失裝置的情況，大部分的視訊記憶體 (卡片上的本機 VRAM 和非本機 AGP 記憶體光圈) 都必須透過使用 Managed 資源或自訂資料結構來支援實體記憶體。 有些高階視訊卡的 VRAM 大小會讓低階 CPU 記憶體的大小變得不同。 相較于視訊卡，系統有有限的實體記憶體，大部分的 VRAM 都無法有效地使用，而且應該設定較低的詳細資料設定。

Real-Time音訊取樣率轉換的Over-Reliance

當音訊系統需要在混合期間將播放速率轉換成硬體緩衝區時，就會發生另一個常見的 CPU 迴圈消耗來源。 使用 Windows 驅動程式模型 (WDM) 驅動程式時，硬體緩衝區格式不會處於直接應用程式控制之下，因為它是核心層級資源;相反地，系統會根據所有來源的最高品質格式和硬體的功能來選取格式。 根據預設，Windows XP 會針對此程式使用高品質的取樣率轉換，而且如果大部分的音訊樣本需要速率轉換，將會耗用大量 CPU 週期。

建議您使用相同的取樣率建立所有 DirectSound 緩衝區。 如果您利用 Microsoft Win32 waveOut 函式，也應該使用這些函式的一致取樣率。 使用 WDM 驅動程式時，緩衝區全都會由核心混合，而且如果您在其中部分使用較高的取樣率，則會將所有其餘部分的取樣率轉換為相符。 請注意，這表示對所有音訊範例使用相同的播放速率，包括任何串流音訊解壓縮緩衝區。 除非您以 Windows 98 或 Windows Large Edition 為目標，否則設定主要緩衝區速率沒有任何作用。

注意

在 Windows Vista 和更新版本的作業系統上，DirectSound 和 waveOut 會針對所有音訊輸出使用 Windows 音訊會話 API (WASAPI) 。

 

虛擬記憶體片段

我們已看到一些與進程記憶體空間 32 位限制相關的最近問題。 雖然使用者模式進程的 2 GB 虛擬位址空間過去已超過足夠，但增加使用大型記憶體對應檔案、自訂記憶體配置器，以及增加 VRAM 大小 (必須對應到進程空間) 已開始造成虛擬記憶體空間配置失敗的情況。 某些非 Microsoft DLL 會在虛擬位址空間中間使用固定啟動位置，這會導致分散導致配置失敗。

當遊戲使用嘗試配置大量連續虛擬記憶體空間區塊的自訂記憶體配置配置時，最常會出現這些問題。 我們建議撰寫配置器，使其視需要要求更合理大小的虛擬位址空間部分。 例如，一次要求 64 或 256 MB，但不是 1 GB。 不過，應該小心不要造成進一步的片段。 64 位作業系統和硬體的出現未來將大幅協助這些問題，但必須小心處理目前的 32 位系統。

操作Floating-Point控制項Word

作為偵錯協助工具，某些開發人員已透過浮點控制字的操作，在浮點單位 (FPU 上啟用例外狀況) 。 這樣做非常有問題，而且可能會導致程式損毀。 就像呼叫慣例要求保留 ebx 暫存器一樣，大部分的系統假設 FPU 處於預設狀態、會提供合理的結果，而且不會產生例外狀況。 驅動程式和其他系統元件通常會根據假設標準錯誤值出現在暫存器中是否有不良狀況，但如果啟用例外狀況，這些驅動程式和其他系統元件通常會計算結果，並導致損毀。

Direct3D 會將浮點單位設定為單精確度、四捨五入為呼叫執行緒初始化的一部分，除非使用D3DCREATE_FPU_PRESERVE旗標，在此情況下，浮點控制字是未觸控的。 由於控制字是每一線程設定，因此確保所有應用程式執行緒都設定為單精確度模式可能會將效能優化。 請記住，呼叫 _control87 對 x64 原生程式碼無效，其會改用 SSE，而且在 Xbox 360 CPU 的 PowerPC 架構上非常昂貴。

注意

如果您修改控制項字組，請使用 _controlfp_s， 並注意對於 x64 平臺，您無法透過控制字變更浮點精確度。

 

在任何需要有不同進位規則或其他行為的程式庫中，例如處理軟體頂點著色器或編譯，我們會儲存並還原控制字組。 如果遊戲需要使用非標準進位或 FPU 例外狀況，它應該儲存並還原浮點控制字，而且您應該確定它不會呼叫尚未證明無法從這些問題保護的任何外部程式碼，包括系統 API。

DirectX 執行時間的選擇性安裝

許多遊戲會詢問使用者是否要安裝 DirectX。 如果使用者假設系統已安裝最新的 DirectX 可轉散發套件並略過安裝，且後續安裝成功，這可能會導致問題。 如果遊戲需要特定版本的 D3DX，或未安裝的其他更新功能，遊戲將無法運作，而且使用者會感到非常挫折。

強烈建議遊戲的安裝程式以無訊息方式安裝遊戲所建置的 DirectX 可轉散發套件。 DirectX 安裝程式的設計目的是要驗證是否有任何專案需要更新，並在未更新時快速傳回。 因此，不需要要求使用者安裝 DirectX。

您可以從安裝套件執行此命令來完成 DirectX 的無訊息安裝： dxsetup.exe /silent

此外，可轉散發資料夾的實際大小可以設定為只包含遊戲目標平臺和使用方式所需的封包檔案 (.cab) 。

注意

使用 dxsetup之前，請閱讀 Not So Direct Setup。

 

過度使用執行緒同步處理

分析遊戲時，通常會發現熱門熱點與進入和離開重要區段有關。 隨著多核心 CPU 的普及，在遊戲中使用多執行緒已大幅增加，許多實作都依賴大量使用執行緒同步處理。 即使沒有任何爭用，仍需要重要區段的 CPU 時間相當重要，而所有其他形式的執行緒同步處理成本會更高。 因此，請務必小心，才能將這些基本類型的使用降到最低。

遊戲中過度同步處理的常見來源是使用 D3DCREATE_MULTITHREADED。 這個旗標雖然讓 Direct3D 執行緒安全可從多個執行緒轉譯，但採用非常保守的方法，因而產生高同步處理額外負荷。 遊戲應該避免此旗標。 相反地，建構引擎，讓 Direct3D 的所有通訊都是來自單一線程，而執行緒之間的任何通訊都會直接處理。 如需設計多執行緒遊戲的詳細資訊，請參閱 針對 Xbox 360 和 Microsoft Windows 上的多個核心撰寫程式碼一文。

使用 RDTSC

不建議使用 x86 指令 RDTSC 。 RDTSC 無法正確計算某些電源管理配置上的計時，這些配置會動態變更 CPU 頻率，以及在核心之間未同步處理許多多核心 CPU 上。 遊戲應該改用 QueryPerformanceCounter API。 如需 RDTSC 和使用 QueryPerformanceCounter實作高解析度計時問題的詳細資訊，請參閱 遊戲計時和多核心處理器一文。