同一隻遊戲 DX11／DX12／Vulkan 點揀先啱？現代遊戲 API 架構、CPU 負擔、著色器編譯同逐遊戲對照指南

2026-10-26 ｜ 顯示卡維修 ｜ 約15分鐘 ｜ HK GPU Fix 編輯部

重點摘要

同一隻遊戲提供多個圖形 API，選擇唔係愈新愈好：要睇 CPU 提交負擔、著色器編譯方式同逐個場景對照，先至揀到最順嘅組合。

點解同一隻遊戲會有幾個 API 選項

現代遊戲喺設定入面成日會見到 DirectX 11、DirectX 12、Vulkan 幾個選項，有啲仲會分開列出，畀玩家自己揀。呢個現象背後有一個好實際嘅原因：遊戲引擎要將畫面指令交畀顯示卡，而交指令嘅方法唔只一種。唔同方法對 CPU 嘅要求唔同，對驅動程式嘅依賴唔同，對舊硬件同新硬件嘅適應力亦都唔同。開發團隊提供多個選項，目的唔係要玩家逐個試運氣，而係畀唔同配置嘅電腦都有機會搵到一個相對穩定嘅路徑。

值得留意嘅係，API 選項本身唔等於畫質選項。轉 API 未必會令貼圖變靚，亦未必會令光影變真。大部分情況下，同一組畫質設定之下，唔同 API 畫出嚟嘅畫面應該好接近，差別主要喺流暢度、幀率穩定性同埋載入過程嘅表現。如果你轉完 API 之後覺得畫面突然變靚好多，好可能係其他設定一齊被重置，或者係驅動程式嘅預設處理方式唔同，而唔係 API 本身直接提升咗畫質。理解呢一點，先唔會將注意力放錯地方。

圖形 API 到底係咩

簡單講，圖形 API 係遊戲程式同顯示卡驅動程式之間嘅一套約定。遊戲引擎唔會直接指揮顯示卡嘅每一個電路，佢會透過 API 發出一連串指令，例如話要畫邊個模型、用邊張貼圖、點樣打光、點樣處理陰影。驅動程式收到指令之後，再翻譯成顯示卡硬件識得執行嘅工作。呢層中間層做得好唔好，直接影響 CPU 要做幾多翻譯同管理工作，以及顯示卡收到嘅工作夠唔夠連貫。

舊式嘅高階 API 會幫開發者做比較多嘢，例如自動管理資源狀態、自動處理同步、喺背後做一啲最佳化。代價係 CPU 要喺每次畫一幀之前做比較多準備工作，而且好多工作集中喺一條主線程上面。新式嘅低階 API 就反過來，將更多控制權交畀開發者，容許遊戲將提交工作分拆去多條線程，減少 CPU 喺關鍵路徑上嘅等待。不過控制權愈多，責任亦都愈大：遊戲引擎要自己管理得好，效果先會出嚟；管理得唔好，反而可能出現更多不穩定或者效能波動。

所以揀 API 唔係揀一個抽象嘅「新定舊」，而係揀一種分工方式：究竟係畀驅動程式幫手管多啲，定係畀遊戲引擎自己管多啲，邊一種分工喺你部機上面跑得順啲。呢個答案因硬件組合、驅動程式版本同遊戲引擎嘅成熟程度而異，冇一個放諸四海皆準嘅答案。

DX11 嘅架構特點

DirectX 11 屬於比較成熟嘅高階 API。佢嘅設計年代，遊戲畫面嘅複雜度同今日唔同，CPU 核心數目亦都普遍較少。喺呢個架構之下，指令提交主要由一條線程負責，驅動程式會喺背後處理好多狀態管理同同步工作。對開發者嚟講，呢種模式比較容易寫得穩定；對玩家嚟講，喺 CPU 效能足夠、場景唔算極端複雜嘅情況下，表現往往相當平順。

不過當場景入面嘅物件數量、材質切換次數同繪製呼叫數量不斷上升，單線程提交嘅瓶頸就會慢慢浮現。CPU 喺每一幀都要逐一準備同提交大量細碎指令，顯示卡有時會因為等唔切下一批工作而出現短暫空閒。呢種情況唔一定表現為平均幀率大幅下跌，更多時候係幀率波動變大，或者喺物件密集嘅場景突然窒一下。喺 CPU 相對較弱、但顯示卡仲有餘力嘅電腦上面，呢個瓶頸會更加明顯。

DX11 嘅另一個特點係驅動程式嘅最佳化空間比較大。因為 API 層面幫手做咗唔少管理，驅動程式廠商可以喺背後針對熱門遊戲做調整，某啲情況下可以彌補引擎本身唔夠最佳化嘅地方。呢個亦都解釋咗點解有啲遊戲喺 DX11 模式下反而特別穩定：唔係 DX11 本身比較快，而係成條鏈路——引擎、API、驅動程式——喺呢個組合之下磨合得比較好。

DX12 同 Vulkan 嘅低階路線

DirectX 12 同 Vulkan 屬於低階 API，設計目標之一就係降低 CPU 提交負擔，並且容許平行提交。遊戲引擎可以將唔同物件嘅指令準備工作分派去多條 CPU 線程，最後再合併提交畀顯示卡。理論上，呢種做法可以減少單線程瓶頸，令 CPU 比較容易餵飽顯示卡，尤其喺繪製呼叫數量龐大嘅場景入面，效果會比較明顯。

但低階唔等於自動快。低階 API 將資源管理、同步屏障、記憶體配置等工作交畀引擎，引擎要寫得夠嚴謹先可以發揮優勢。如果引擎喺某啲路徑上處理得唔夠好，例如同步等得太耐、資源切換太頻密，表現反而可能差過成熟嘅 DX11 路徑。實際上，唔少遊戲喺 DX12 或者 Vulkan 模式下推出初期都經歷過一段磨合期，之後透過更新先慢慢穩定落嚟。呢個過程本身好正常，唔代表低階 API 有問題，只係話「新架構」需要時間去寫好。

平台支援亦都係一個考慮因素。DirectX 12 主要對應 Windows 生態，Vulkan 嘅跨平台特性比較強，喺唔同作業系統同裝置上面都有應用。對一般 Windows 玩家嚟講，兩者嘅實際差別唔在於名氣，而在於邊一個喺呢隻遊戲、呢個驅動程式版本、呢部機上面跑得穩。唔好因為聽聞某個 API 比較先進，就假設佢喺所有遊戲入面都一定比較好。

CPU 負擔點樣轉化為你感受到嘅窒

講到 CPU 負擔，好多人會直接諗起 CPU 使用率，但使用率高低本身唔係最準確嘅指標。真正影響感受嘅，係 CPU 能唔能夠喺顯示卡需要下一幀工作之前，準時準備好所有指令。如果 CPU 準備得慢，顯示卡就會有一段時間冇嘢做，幀與幀之間嘅間隔就會拉長，畫面就會窒。就算平均幀率睇落唔差，間隔唔均勻都會令操作感覺唔順。

另一個常見情況係 CPU 瓶頸同顯示卡瓶頸交替出現。喺空曠場景，顯示卡負擔輕，CPU 可能成為限制；去到物件密集或者特效繁多嘅場景，顯示卡負擔加重，限制又轉返去顯示卡。呢種交替會令幀率曲線起伏不定。轉 API 之後如果覺得某啲場景順咗、某啲場景反而差咗，好可能就係瓶頸位置轉移咗，而唔係整體效能單向提升或者下跌。

判斷係咪 CPU 提交問題，有幾個觀察方向可以參考。第一係降低畫質設定之後，幀率有冇明顯上升：如果將貼圖、陰影、解析度等顯示卡負擔較大嘅選項調低，幀率依然變化唔大，咁限制好可能喺 CPU 一邊。第二係觀察唔同場景嘅表現差異：物件多、切換多嘅場景特別差，空曠場景相對正常，呢個模式比較符合提交負擔嘅特徵。第三係留意驅動程式同遊戲更新之後嘅變化：如果某次更新之後某個 API 模式突然變順或者變差，咁好可能係引擎或者驅動程式喺提交路徑上改咗嘢。

著色器編譯同管線建立嘅角色

轉 API 之後，另一個成日被忽略嘅環節係著色器編譯同管線建立。唔同 API 嘅著色器格式同管線狀態組合唔同，遊戲第一次用某個 API 進入某個場景、第一次遇到某種材質或者特效組合嗰陣，可能需要即場編譯或者建立對應嘅管線。呢個過程會佔用時間，表現出嚟就係短暫窒一下，之後再入同一個場景就會順好多。

呢個現象同首次運行著色器編譯卡頓有關係，但唔完全等同。舊遊戲嘅 API 相容問題、首次編譯卡頓、畫面生成技術帶嚟嘅延遲、更新之後效能倒退嘅比較方法，各自都有專文討論，喺度只係提一提邊界：如果你轉完 API 之後頭幾分鐘特別窒，但之後慢慢穩定，唔好即刻斷定呢個 API 唔啱；應該畀佢行多幾次同類場景，等編譯快取建立好之後再比較。反過嚟講，如果每次入同一個場景都同樣窒，咁就唔係單純嘅首次編譯問題，而係要再睇提交負擔或者其他環節。

著色器快取亦都解釋咗點解轉 API 之後，第一次比較同第二次比較可以得出唔同結論。好多遊戲會將編譯好嘅結果儲存落嚟，下次再用就唔使重新編譯。所以比較方法好重要：每一個 API 都應該畀佢行過一次完整流程之後，先至做正式對照，否則你比較緊嘅可能唔係 API 架構，而係「邊個啱啱編譯完」同「邊個未編譯」嘅分別。

點揀：一個實用嘅決策流程

揀 API 唔需要一次過諗晒所有理論，用一個有次序嘅流程會實際得多。首先睇遊戲本身嘅預設值：開發團隊通常會將比較成熟、測試覆蓋較廣嘅模式設為預設，預設值係一個合理嘅起點，唔係隨意揀出嚟嘅。其次睇你部機嘅瓶頸傾向：如果 CPU 相對較弱、場景物件密集，低階 API 值得一試；如果部機整體均衡、而 DX11 模式已經好順，就唔使為咗追新而轉。

以下對照表總結咗三種 API 嘅一般取向，實際表現仍然要以逐遊戲對照為準：

流程上，建議每次只試一個 API，試完之後用同一個場景、同一個畫質設定去感受同記錄，唔好同時改埋畫質、解析度或者其他選項。如果試完兩個模式都差唔多，揀返預設或者較穩定嗰個就可以，唔使為咗微小差異反覆折騰。反之，如果某個模式喺你常玩嘅場景明顯穩定好多，嗰個就係你部機嘅答案，唔使理會網上其他配置嘅結論。

逐遊戲對照方法：一次只改一個變數

要比較得準，方法比結論更重要。最常見嘅錯誤係一次過改好多嘢：轉 API 之餘又調高畫質、又開埋其他功能，最後根本唔知邊個改動帶嚟變化。正確做法係固定所有其他條件，只改 API 一項，然後用同一個場景重複行幾次。

對照流程可以參考以下步驟。第一步，選定一個對你嚟講有代表性嘅場景，例如物件密集嘅市區、戰鬥頻繁嘅區域或者你成日會返去嘅地點，唔好只用主選單或者空曠地方做比較。第二步，將畫質、解析度、幀率上限、垂直同步等設定全部固定落嚟，寫低佢哋，確保兩個模式用同一組設定。第三步，每個 API 先行一次完整流程，等著色器快取建立好，之後再正式記錄幾次結果。第四步，記錄嘅重點唔止平均幀率，仲要留意最低幀率走勢、窒嘅頻率同埋窒出現嘅位置。第五步，如果兩個模式各有勝負，就以你最常玩、最在意嘅場景做最終決定。

呢個方法嘅好處係結論屬於你自己部機，而唔係抄返嚟嘅。同一隻遊戲喺唔同硬件組合上面可以有完全唔同嘅最佳選擇，所以網上講到某個 API 一定比較好嘅說法，聽完之後都應該用自己嘅對照去驗證一次。

常見誤區

第一個誤區係「愈新嘅 API 一定愈快」。新架構提供咗減輕 CPU 負擔嘅可能性，但係咪真係快，要睇引擎寫得好唔好、驅動程式磨合得好唔好、場景特性啱唔啱。喺某啲遊戲入面，成熟嘅 DX11 路徑反而因為驅動程式最佳化做得足，表現更加穩定。

第二個誤區係「轉 API 可以解決所有窒」。如果窒嘅原因係顯示卡本身效能唔夠、散熱受限、記憶體不足或者遊戲本身有其他問題，轉 API 幫助有限。API 只係指令提交嘅一環，唔係萬能藥。轉完 API 之後完全冇改善，唔代表你試錯咗，而係提示你要將檢查範圍擴大，去睇其他環節。

第三個誤區係「一次比較就夠」。頭一次行新 API 嗰陣，著色器編譯同快取建立會影響結果；驅動程式更新之後，磨合情況亦都可能改變。所以比較應該喺快取建立好之後做，而且喺大更新之後值得再做一次簡單對照，唔好將幾個月前嘅結論當成永久答案。

第四個誤區係將唔同遊戲嘅結論互相套用。某隻遊戲喺 DX12 之下表現出色，唔代表另一隻遊戲都會一樣，因為兩隻遊戲嘅引擎、提交模式同最佳化程度完全唔同。每隻遊戲都應該獨立對照一次，呢個步驟雖然麻煩，但係唯一可靠嘅方法。

邊界：幾時唔好再糾結 API

如果你已經用上面嘅方法對照過，而兩個模式差別唔大，咁就唔使再花時間糾結，揀返較穩定嗰個，將精力放喺遊戲設定同操作體驗上面。相反，如果你發現無論轉邊個 API，某啲場景都同樣窒、甚至伴隨住畫面異常、閃爍或者崩潰，咁問題好可能已經超出 API 選擇嘅範圍，需要檢查驅動程式版本、系統設定、散熱同硬件狀態，或者向遊戲開發團隊回報相關情況。

另外有幾類主題，喺度只會點到即止，因為佢哋各自有更深入嘅討論：舊遊戲嘅傳統 API 相容問題、首次運行著色器編譯卡頓、畫面生成技術帶嚟嘅延遲感受，以及更新之後效能倒退嘅比較方法。將呢啲主題分開處理，可以避免將唔同成因嘅窒混為一談，診斷先會準確。

如果你對照完之後仍然唔肯定，或者發現問題伴隨住其他硬件異常，例如顯示卡風扇噪音異常、溫度長期偏高、畫面出現破圖等情況，可以考慮尋求專業檢查。香港顯示卡維修方面，HK GPU Fix 位於石門達利廣場 1209 室，電話 2186 8010，WhatsApp 6558 6806，檢查前可以先講清楚你已經試過邊幾個 API 模式同埋對照結果，咁樣可以節省來回溝通嘅時間。

常見問題

問：同一隻遊戲有 DX11 同 DX12，預設嗰個係咪一定最好？

答：預設通常係開發團隊測試覆蓋較廣、相對成熟嘅選擇，係一個好嘅起點，但唔等於喺每一部機上面都最好。預設值係為大多數配置而設，你部機嘅 CPU 同顯示卡組合可能令另一個模式更啱，所以值得用固定場景做一次簡單對照，再決定係咪跟預設。

問：轉咗 DX12 之後頭幾分鐘特別窒，係咪代表 DX12 唔啱我？

答：未必。轉 API 之後，著色器同管線需要重新建立同快取，頭幾次入場景可能會窒。建議畀每個模式行多幾次同類場景，等快取建立好之後再比較。如果每次入同一個場景都同樣窒，先至可以話呢個模式喺呢個場景真係有問題。

問：Vulkan 同 DX12 邊個比較好？

答：冇通用答案。兩者都係低階路線，都容許平行提交，實際表現取決於遊戲引擎點樣用佢哋，以及驅動程式磨合得點。邊隻遊戲提供邊個選項、邊個模式喺你部機上面較穩定，先係判斷標準，唔好單憑 API 名稱去排高低。

問：轉 API 之後畫質設定會唔會自動變咗？

答：有機會。某啲遊戲轉 API 之後會重置部分設定，或者某啲選項喺唔同 API 之下嘅預設值唔同。對照之前，一定要逐項檢查畫質、解析度同幀率上限係咪一致，否則比較結果根本唔成立。

問：CPU 比較弱嘅電腦，係咪一定要用 DX12 或者 Vulkan？

答：唔一定，但值得優先試。低階 API 有機會減輕單線程提交瓶頸，對 CPU 相對較弱嘅情況有幫助。不過如果引擎喺低階模式下寫得唔夠成熟，或者驅動程式磨合未夠好，成熟嘅 DX11 模式反而可能更穩定，所以最終都係要靠自己部機嘅對照結果去決定。

問：點解網上有人話某個 API 快好多，但我試落完全唔覺？

答：因為對照條件唔同。硬件組合、場景選擇、驅動程式版本、著色器快取狀態，任何一項唔同都可以令結論唔同。最可靠嘅做法係用自己部機、自己常玩嘅場景、固定其他設定去對照一次，唔好直接將人哋嘅結論套落自己部機上面。