遊戲入場轉場窒一下點解？著色器編譯卡頓、PSO 預編譯同驅動快取完整排查指南
重點摘要
遊戲入場或轉場先窒一下、之後順返，多數係著色器即時編譯所致，畀快取起好同完成預編譯，之後再行同一場景就會明顯改善。
呢篇係咪講緊你嘅問題
如果你遇到嘅情況係：平均幀數睇落唔差，但一入遊戲、一入新地區，或者第一次見到某種新效果、新敵人、新武器、新天氣、新光影狀態嗰陣，畫面會突然停一停、窒一下，之後同一場景再行就順晒，咁呢篇好大機會就係講緊你嘅問題。另一種情況就唔係：同一個位每次行過都窒足一樣，唔理你行過幾多次都冇改善，咁就要先懷疑串流載入、處理器樽頸或者記憶體壓力，而唔係著色器編譯。
仲有一個好有用嘅分界：如果問題係喺你更新驅動程式、重裝驅動程式、清過快取、轉過顯示卡，或者遊戲大更新之後先開始出現，而且行多幾次同一場景會慢慢好返，咁著色器快取重建嘅可能性就更高。相反，如果問題喺所有遊戲、包括好舊嘅遊戲都出現，仲伴隨當機、畫面錯亂或者溫度風扇異常，咁就已經唔係單純「第一次先窒」嘅故事，值得用另一種思路去檢查硬件同散熱。
著色器係咩，點解一定要喺你部機即場編譯
著色器係一細段喺顯示卡上面執行嘅程式，負責描述一樣嘢點樣畫出嚟：表面質感、光影、陰影、透明效果、後期處理、粒子、光線追蹤等等。遊戲本身並唔係直接帶住一早就寫好、畀所有顯示卡即刻用得嘅機器碼出貨，而係帶住一種中間形式嘅著色器，交由顯示卡驅動程式翻譯成配合你部機嘅顯示卡型號同驅動程式版本嘅機器碼。因為每部電腦嘅組合都唔同，呢一步冇辦法由開發者一次過為全世界所有電腦預先做晒。
喺現代圖形介面 DirectX 12 同 Vulkan 入面，編譯好嘅著色器會連同其他渲染狀態一齊包成一個叫管線狀態物件嘅組合，英文簡稱 PSO。呢個組合除咗著色器本身，仲包括混合模式、深度測試、光柵化設定、渲染目標格式等等參數。建立一個新嘅 PSO 係一個會阻塞成個流程、需要幾毫秒甚至更長時間嘅操作。如果遊戲喺打機途中先突然要求一個從來未建立過嘅 PSO，嗰一幀就一定要等編譯完成先可以繼續，結果嗰一幀嘅時間遠遠超出正常預算：60 幀每秒嘅正常預算大約係 16.7 毫秒，120 幀每秒就大約係 8.3 毫秒。一旦超出，玩家就會感覺到一下明顯嘅窒動。
仲有一個關鍵位：編譯工作本身係由處理器去做，唔係顯示卡。呢個解釋到點解一部處理器較快嘅電腦，窒動嘅幅度會細啲，但唔會因此完全消失；亦都解釋到點解一張好強嘅顯示卡一樣可以窒得好勁，因為顯示卡嗰陣只係喺度等，等處理器完成編譯。所以「換張更勁嘅卡就一定順」呢個諗法，喺著色器編譯呢個問題上面並唔成立。
點解 DirectX 12 同 Vulkan 之後，呢個問題變得更加明顯
喺 DirectX 11 時代，驅動程式會幫手管理較多管線狀態，著色器多數喺載入畫面嗰陣一次過編譯好，載入時間長啲，但入到遊戲之後就順啲。DirectX 12 同 Vulkan 係更加貼近硬件嘅低階介面，將管線狀態嘅控制權交咗畀開發者，換嚟效能潛力，但同時將即時建立 PSO 嘅責任都交埋畀開發者。如果開發者冇預先暖好玩家有機會遇到嘅所有 PSO，第一次遇到就會即場編譯，玩家就會感覺到窒動。
遊戲機之所以較少受呢個問題困擾，原因係硬件固定：開發者可以為一個已知嘅顯示卡組合預先編譯好著色器。電腦做唔到同一樣嘢，因為硬件同驅動程式嘅組合實在太多。有人會問，點解唔索性將所有可能組合一次過預編譯晒？因為一個素材可以配合好多變數：動態定靜態光影、陰影開定關、光線追蹤開定關、抗鋸齒模式、透明效果等等，組合起嚟數量可以非常龐大。全部預編譯會令快取體積同載入時間都大增，仲要包括好多玩家永遠唔會遇到嘅組合。所以即使一隻遊戲有「編譯緊著色器」嘅畫面，之後仍然有機會因為某個冇預先覆蓋嘅光影加特效組合而窒一下，呢個並唔罕見。
著色器快取有三層，唔好混為一談
編譯過一次嘅著色器同 PSO 結果，會儲存喺磁碟上面嘅著色器快取入面，下次再需要同一個著色器嗰陣，就可以直接由快取載入，唔使再編譯，呢個就係「第一次先窒，之後順」嘅原因。但快取其實有三層，作用唔同，唔好混埋一齊講。
| 快取層次 | 幾時發生 | 作用 | 注意事項 |
|---|---|---|---|
| 遊戲或者引擎預編譯畫面 | 首次啟動遊戲嗰陣，見到「編譯緊著色器」之類嘅畫面 | 遊戲將已知嘅 PSO 喺入遊戲之前先編譯好 | 跳過呢一步唔係慳咗工夫，只係將工夫推咗入遊戲途中變成窒動 |
| 驅動程式著色器快取 | 遊戲運行期間，驅動程式將編譯好嘅二進制結果儲存落嚟 | 下次用同一驅動程式同顯示卡組合嗰陣直接載入 | NVIDIA 控制面板有著色器快取大小設定，一般建議保留喺驅動程式預設或者更大，太細會迫使已經編譯好嘅著色器重新編譯；AMD 方面則由驅動程式自動管理快取大小 |
| 平台預先快取 | 例如 Steam 設定入面嘅著色器預先快取 | 預先為遊戲準備著色器，減少首次遊玩嘅編譯工作 | 據資料所指，呢類預先快取主要針對 Vulkan 同 OpenGL 遊戲，唔好期望佢可以解決 DirectX 12 遊戲嘅窒動 |
喺 Windows 上面，驅動程式快取同系統 DirectX 快取嘅位置，據多個資料來源所指，包括 NVIDIA、AMD 同 Intel 各自喺使用者本機應用程式資料夾下面嘅 DXCache，以及系統嘅 D3DSCache。一般使用者唔需要記住呢啲路徑，亦都唔需要成日去清理佢哋，知道佢哋存在、知道清理之後要重新建立，已經足夠。
另外有一個正在發展嘅方向，值得用保留態度去理解：微軟嘅進階著色器傳送技術，據 2025 至 2026 年嘅報道所指，會將預編譯工作搬去雲端，由開發者將著色器資料交出，再由商店為多種硬件同驅動程式組合預先編譯。報道亦提到個別新驅動程式已經支援呢個機制，同埋有廠商聲稱快取命中率接近百分之百。不過呢啲屬於廠商方面嘅講法，實際覆蓋範圍會視乎個別遊戲同商店而定，唔應該理解為「呢個問題而家已經全面解決」。寫到呢度都要講清楚，遊戲支援同商店支援都係逐隻逐個睇，唔好一概而論。
點解更新驅動程式或者重裝之後，窒動會返嚟
編譯好嘅著色器二進制結果，係同產生佢嗰個驅動程式同顯示卡掛鈎。當驅動程式更新、重裝，或者遊戲更新改動咗著色器，舊嘅快取項目有機會失效或者被棄用，著色器就要重新編譯。實際後果就係：更新驅動程式之後，預期會有一個比較窒嘅遊戲時段，之後隨住重複行返同一啲地區，快取慢慢重建，窒動就會逐漸減少。
呢個亦都解釋到點解一見到更新完變窒就即刻回滾驅動程式，好多時並唔係最好嘅反應。因為回滾本身都可能令快取再次失效，變相又要重新編譯一次。同一個道理亦都適用於人手清除著色器快取、轉顯示卡牌子或者型號、重裝 Windows，以及部分會改動著色器嘅遊戲更新。清除快取唔係日常保養，資料來源嘅共識係只應該喺懷疑快取損壞嗰陣先做，例如同一場景重複行好多次都完全冇改善。清除快取唔會刪除遊戲設定或者存檔，因為快取入面只係儲存編譯好嘅著色器，唔係玩家資料。但清除之後，下一個遊戲時段一定會比較窒，因為快取要重新建立，呢一點要預先有心理準備。
仲要留一個不確定嘅位：究竟某一次驅動程式更新會令成個快取失效，定係只係部分失效，資料來源嘅講法比較概括，實際情況可能因牌子、驅動程式版本同遊戲而異。所以穩陣嘅講法係「有機會令快取失效」，而唔係「一定會成個清晒」。
點樣量度，先至唔會俾平均幀數呃到
平均幀數會掩蓋呢個問題。一隻遊戲平均可以做到 120 幀，但如果個別幀由大約 8 毫秒突然跳到幾十毫秒，體感仍然會好差。所以要學識睇幀時間，即係每一幀用幾多毫秒，同埋 1% 同 0.1% 低位數值，唔好淨係睇幀數計數器。
常用工具包括 CapFrameX、PresentMon 本身、MSI Afterburner 配合 RTSS 嘅幀時間圖表，以及 HWiNFO64。做法係揀一條可以重複行 60 至 90 秒嘅路線，擷取幾次數據，重點睇圖表形狀，而唔係淨係睇總結數字。孤立嘅高尖峰指向編譯、串流載入或者中斷問題；成段都好嘈雜嘅波動，就比較指向處理器樽頸或者同步問題。有資料提到冷快取同暖快取喺同一條路線上面測試，平均值可以好接近，但 0.1% 低位數值可以差好遠，呢個正正說明點解淨係睇平均值會誤導。不過嗰個測試嘅具體數字只係該資料來源自己嘅測試，唔應該當成通用事實去引用。
有兩個診斷測試特別針對著色器窒動。第一個係重複行同一條路線兩次，中間咩都唔改：著色器窒動喺第二次會明顯減少，串流、處理器或者顯示記憶體問題就會重複出現。第二個係清除驅動程式著色器快取之後，再行同一條路線：如果窒動返返嚟，而且位置都係第一次遇到新效果嘅地方，編譯嘅嫌疑就好大；如果清除前後完全冇分別，就要向其他方向查。不過要提醒，呢個測試本身會刻意製造一個好窒嘅時段，做之前要知會自己一聲，唔好喺重要嘅遊戲時段入面做。
分辨表：窒一下有好多種，唔好一概歸咎著色器
| 疑似原因 | 玩家見到嘅特徵 | 點樣檢查 | 點樣排除或者確認 |
|---|---|---|---|
| 著色器或者 PSO 編譯 | 第一次遇到某種效果或者地區先窒，重複行會好返；驅動程式更新、清快取或者遊戲更新之後會返嚟 | 幀時間圖表喺遊戲初期有孤立高尖峰；同一條路線第二次行會乾淨好多 | 每次行都一模一樣咁窒，唔理快取狀態，咁就唔係呢個原因 |
| 顯示記憶體耗盡 | 貼圖突然變模糊或者低清、轉身或者入密集地區嗰陣窒；顯示記憶體用量接近上限 | 睇顯示記憶體用量疊加顯示；試下降低貼圖質素或者解像度睇下有冇改善；留意已分配嘅顯示記憶體唔等於實際需要嘅顯示記憶體，唔好單憑一個數字就下定論 | 降低貼圖設定之後有改善，而且暖快取之後仍然存在，就偏向呢個方向 |
| 處理器樽頸 | 幀數唔穩定，但顯示卡使用率遠低於九成幾；降低解像度或者開超解析都幾乎唔影響幀數；密集地區、城市、大型戰鬥或者多人遊戲大廳特別差 | 睇逐核心處理器用量，單一核心跑滿已經可以成為樽頸，就算整體處理器用量睇落唔高；做降低解像度測試 | 降低解像度之後幀數明顯上升，就比較偏向顯示卡受限 |
| 系統記憶體或者分頁檔壓力 | 喺記憶體壓力之下出現窒動；已認可記憶體接近總記憶體；資源監視器入面持續出現硬錯誤 | 工作管理員效能分頁睇記憶體用量；試下關閉背景程式再對照 | 睇唔到記憶體壓力，就唔係呢個原因 |
| 世界串流或者素材載入 | 每次跨過同一個世界邊界或者生成同一個重型角色嗰陣都窒，唔似著色器窒動咁只係每段遊戲時段一次 | 同一條路線重複測試；遊戲放喺硬碟定固態硬碟都有影響，固態硬碟有助串流，但解決唔到著色器編譯 | 清快取測試冇改變，咁就偏向串流問題 |
| 撕裂 | 畫面橫向裂開，上下半幅顯示唔同幀；感覺反應快，但畫面局部睇落斷開；唔係停頓 | 睇垂直同步同可變更新率設定；幀數愈高，撕裂喺視覺上出現得愈密 | 停頓同窒動唔係撕裂，撕裂唔會令郁動停低 |
| 抖動 | 幀數低過顯示器更新率嗰陣，畫面節奏唔均勻，例如 60Hz 顯示器跑 50 幀，就有啲幀顯示一次、有啲顯示兩次；就算擷取到嘅幀時間睇落正常，郁動都唔順 | 對照幀數同更新率；開可變更新率或者限制幀數 | 淨係睇幀時間圖表會睇唔出呢個問題，問題喺顯示節奏 |
| 可變更新率超出範圍 | 遊戲幀數高過顯示器可變更新率範圍，例如無上限跑到好高幀數，垂直同步延遲會返嚟，間中仲有撕裂，感覺冇限制喺範圍入面咁穩定 | 將幀數限制喺更新率之下幾幀，常見建議係最少低大約 3 幀 | 喺範圍入面嘅可變更新率可以解決大部分節奏問題，但解決唔到好大嘅著色器尖峰 |
| 過熱降頻 | 時脈速度喺圖表上面跌完又回升；表現隨住遊戲時段拉長而變差，而唔係改善 | 睇顯示卡同處理器溫度加時脈疊加顯示 | 著色器窒動會隨住遊戲時段改善，過熱降頻就係愈打愈差 |
仲有兩個常見誤解要講清楚。第一，高幀數唔等於順暢，幀與幀之間嘅節奏比平均值更加重要。第二，幀生成技術，例如 DLSS 幀生成同 FSR 幀生成，係喺已渲染幀之間插入生成幀，令顯示出嚟嘅幀數計數器上升，但唔會加快遊戲本身嘅模擬速度。如果基礎幀率本身已經唔穩定或者偏低，生成幀會繼承嗰種唔均勻，仲會增加輸入延遲，所以幀生成唔係著色器窒動嘅解決方法。
實際幫到手嘅做法，按次序做
第一，首次啟動遊戲嗰陣見到編譯著色器嘅步驟，一定要畀佢完整做完，唔好跳過，預期第一次遊戲時段會長啲。第二，頭幾次遊戲時段，行晒新地區一次，畀快取慢慢建立，唔好憑第一次運行就去判斷一隻遊戲或者一個新驅動程式好唔好。第三，保留驅動程式著色器快取開啟，NVIDIA 方面保留喺驅動程式預設或者更大，唔好為咗慳磁碟空間而縮細，除非磁碟壓力真係迫不得已，而且縮細之後要預期重新編譯。第四，Steam 著色器預先快取可以為 Vulkan 同 OpenGL 遊戲開啟，但要記住佢唔覆蓋 DirectX 12，唔好對佢有超出範圍嘅期望。
第五，用可變更新率配合合理嘅幀數上限，將節奏問題同編譯尖峰分開處理。遊戲內置嘅幀數上限通常延遲最低，RTSS 嘅幀數上限節奏就非常平均。第六，只喺懷疑快取損壞嗰陣先清除著色器快取，即係同一場景重複行都完全冇改善嗰陣，清除之後再行一個有代表性嘅場景去重建快取。第七，將遊戲放喺固態硬碟上面，呢個有助串流窒動，但唔好將佢當成著色器問題嘅解決方法去推銷。第八，更快嘅處理器或者更多記憶體，只係喺邊緣位置有幫助，令尖峰短啲、記憶體壓力細啲，但唔係缺失預編譯嘅根治方法，唔應該將買硬件講成係遊戲層面預編譯不足嘅解決方案。
第九，幾時要懷疑硬件或者送檢：如果窒動喺重複行走之下完全冇改善、喺所有遊戲包括舊遊戲都出現，或者伴隨當機、畫面錯亂、風扇或者溫度異常，咁就已經唔再係「第一次先窒」嘅故事，需要認真檢查顯示卡健康、散熱、儲存裝置同驅動程式。文章可以提醒讀者去做檢查，但唔可以單憑症狀就斷定係邊個零件壞。
邊緣情況同容易踩中嘅陷阱
一隻遊戲可以同時有著色器窒動同串流窒動，喺開放世界遊戲入面尤其常見，重複行走測試可以將兩者分開，但混合畫面本身並唔出奇。著色器窒動亦都好容易令人誤會係「新驅動程式好差」，其實好多時只係新驅動程式令舊嘅暖快取失效，喺考慮回滾之前，應該先理解呢一層關係。有啲遊戲會喺遊玩期間喺背景編譯著色器，窒動就會分散喺頭一個鐘頭入面出現，而唔係全部集中喺開頭，個別資料來源形容某啲 Unreal Engine 5 遊戲嘅著色器窒動可以持續頭 30 至 60 分鐘，呢個只係該資料來源嘅觀察，唔好當成通用規則。
同一個引擎嘅唔同遊戲，預編譯質素都可以差好遠，取決於製作團隊有冇認真做好預編譯，唔好將成個引擎一概而論去讚或者去鬧。歷史例子方面，個別遊戲喺推出嗰陣曾經出現著名嘅著色器窒動問題，引用嗰陣一定要加「推出嗰陣」呢類時間限定字眼，唔好喺冇註明日期同可查證來源嘅情況下，斷言某隻遊戲而家仍然有問題或者已經修好。最後，唔好對外聲稱任何牌子著色器快取嘅具體容量數字，因為資料來源只係講設定建議，冇一個通用容量數字，個別使用者實際佔用幾多亦都因人而異。
常見問題
問：點解我張卡好勁，遊戲平均幀數又高，但入場嗰陣仲係會窒一下？
答：因為窒動嘅來源未必係顯示卡算力，而係處理器即場編譯著色器同建立管線狀態組合嗰陣，嗰一幀要等編譯完成先可以繼續。平均幀數高唔代表每一幀都準時，孤立嘅長幀已經足夠令人感覺到窒動。
問：更新驅動程式之後變窒，係咪代表新驅動程式有問題，應該即刻回滾？
答：未必。驅動程式更新有機會令舊快取失效，之後要重新編譯，頭一個遊戲時段比較窒係預期之內。建議先行多幾次同一場景，睇下窒動有冇隨住快取重建而減少，再去判斷。回滾本身都有機會令快取再次失效，唔好衝動行第一步。
問：清除著色器快取可唔可以當成日常保養，定期清一次？
答：唔建議。清除快取只應該喺懷疑快取損壞嗰陣做，例如同一場景重複行都完全冇改善。日常清除只會令下一個遊戲時段重新經歷一次編譯窒動，冇任何好處。清除快取亦都唔會刪除遊戲設定或者存檔。
問：Steam 著色器預先快取開咗，點解 DirectX 12 遊戲仲係會窒？
答：因為據資料所指，呢類預先快取主要針對 Vulkan 同 OpenGL 遊戲，唔覆蓋 DirectX 12 遊戲。所以 DirectX 12 遊戲仍然要靠遊戲本身嘅預編譯畫面同驅動程式快取，開咗 Steam 預先快取唔代表所有遊戲都受惠。
問：將遊戲由硬碟搬去固態硬碟，可唔可以解決著色器窒動？
答：固態硬碟有助減少串流載入引起嘅窒動，但解決唔到著色器編譯本身，因為編譯工作係處理器做，唔係儲存裝置做。如果窒動喺重複行走之後會消失，固態硬碟唔係主因；如果每次跨過同一個邊界都窒，固態硬碟先至值得優先考慮。
問：開幀生成可唔可以掩蓋著色器窒動？
答：唔可以。幀生成只係喺已渲染幀之間插入生成幀，令顯示幀數上升，但唔會加快遊戲模擬，基礎幀率唔穩定嗰陣，生成幀仲會繼承嗰種唔均勻同增加輸入延遲。著色器窒動要由預編譯同快取去處理，唔係由幀生成去掩蓋。
問：幾時先值得懷疑係硬件問題，而唔係著色器編譯？
答：當窒動喺重複行走之下完全冇改善、喺所有遊戲包括舊遊戲都出現，或者伴隨當機、畫面錯亂、風扇或者溫度異常，嗰陣就唔再係典型嘅著色器故事，值得進一步檢查顯示卡健康、散熱、儲存裝置同驅動程式，而唔好單憑症狀就斷定邊個零件壞。
檢查同收費
如果行晒上面嘅分辨方法，仍然分唔出係著色器預編譯不足、串流問題、處理器樽頸、記憶體壓力定係顯示卡本身有問題，可以將成套組合帶去檢查。檢查及維修收費分三級，HK$400 至 HK$2,800，實際以檢查後報價為準。地址係石門達利廣場 1209 室，電話 2186 8010，WhatsApp 6558 6806。