Mesa 納入 Rust KRAID,Arm Mali 進入新編譯路線
Mesa 26.2 把 Rust 編寫的 KRAID shader compiler 納入 Arm Mali v9+ GPU 路徑,先從 Panfrost 與 PanVK 開始,並已通過首個 dEQP 測試。

Mesa 26.2 已納入 Rust 編寫的 KRAID,讓 Arm Mali v9 以上 GPU 的 shader 編譯多了一條新路線。
這次變動很實際。它不是把 Rust 放在周邊工具,而是直接放進圖形驅動的核心路徑。Mesa 26.2 已把 KRAID 放進樹內,先服務 Panfrost 和 PanVK。它鎖定的是 Arm Mali v9 Valhall 及更新的 GPU。
更直接一點看,這代表 Mesa 開始把 Rust 用在最怕出錯的地方。shader compiler 一旦出問題,畫面就可能花掉、效能掉下來,甚至測試直接失敗。對開發者來說,這種地方最適合拿來驗證 Rust 到底能不能少踩坑。
| 項目 | 內容 |
|---|---|
| Mesa 版本 | 26.2 |
| GPU 目標 | Arm Mali v9 Valhall 以上 |
| 首個測試結果 | 已通過第一個 dEQP 測試 |
| 編譯啟用旗標 | -Dpanfrost-rust |
| 執行時切換 | PAN_USE_KRAID |
KRAID 進 Mesa,改的是哪一段
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析,直送信箱。不定期,不騷擾。
不會寄垃圾信,隨時可取消。
KRAID 是一條新的 shader 編譯路徑。它用 Rust 寫,不再沿用 Mesa 裡那些老牌 C 程式碼的寫法。這件事看起來像語言選擇,實際上是在改驅動內部的風險管理方式。編譯器位在圖形堆疊中間,錯一個最佳化,後面就可能連著出一串畫面問題。

它的目標很明確,先瞄準 Mali v9 Valhall 與更新晶片。這一代 Arm GPU 還活在很多 Linux 筆電、掌機、單板電腦和嵌入式設備裡。也就是說,這不是只給實驗室看看的東西,而是會碰到真實使用情境的驅動路徑。
我覺得這裡最有意思的地方,是 Mesa 沒把 Rust 當裝飾品。它直接碰 shader compiler,等於把 Rust 放到最容易暴露 bug 的位置。這種做法很務實,也很符合開源驅動社群一貫的風格。
- KRAID 已進入 Mesa 主樹,不是旁支專案。
- 它同時服務 OpenGL 的 Panfrost 與 Vulkan 的 PanVK。
- 目標是 Arm Mali v9 Valhall 以上 GPU。
- 它已經通過第一個 dEQP 測試。
Faith Ekstrand 為什麼會讓人注意
這個編譯器專案由 Faith Ekstrand 推動,她任職於 Collabora。在開源 GPU 世界裡,這名字很有份量。她也參與過 NVK,也就是開源 NVIDIA Vulkan 驅動。
"Rust is a great fit for graphics drivers and other systems software." — Faith Ekstrand
這句話很直白。圖形驅動需要速度,也需要穩定。C 語言在這裡不是不能用,而是很多錯誤太容易混進去。Rust 的價值就在於,它能把一部分低階錯誤擋在編譯期,讓開發者少碰一些難追的記憶體問題。
另一個重點是社群流程。KRAID 進了 Mesa 主樹,就代表它要接受同樣的 review、CI 與 release 節奏。這種節奏通常不會很戲劇化,但對驅動維護很重要。圖形堆疊最怕的是私有分支各寫各的,最後沒人敢合併。
怎麼啟用,怎麼驗證
如果開發者想試,路徑已經公開。Mesa 的建置系統提供 -Dpanfrost-rust,可以在編譯時把 Rust 相關路徑打開。執行時也能用 PAN_USE_KRAID 切換編譯器。這表示它不是只停在新聞稿,而是真的能被編、被切、被量測。

第一個 dEQP 測試通過也很重要。dEQP 是圖形驅動常用的相容性與一致性測試,很多細碎 bug 都會在這裡被挖出來。通過一個測試不代表全部都穩,但至少說明這條 Rust 路徑已經走進正式驗證流程。
對台灣開發者來說,這種資訊很有參考價值。很多 Linux 裝置,尤其是 ARM 平台,最後都會碰到 Mesa。你不一定每天改圖形驅動,但你會在板子、筆電、或嵌入式產品上遇到它。驅動層一旦穩一點,整個系統就少很多怪問題。
- dEQP 用來測圖形相容性。
-Dpanfrost-rust是建置時開關。PAN_USE_KRAID是執行時切換。- 這條路線未來可能逐步取代舊的編譯器程式碼。
Rust 進圖形堆疊,意味著什麼
Rust 早就不只用在工具程式。它進入系統軟體、後端服務、核心周邊模組之後,下一個自然目標就是圖形驅動。KRAID 的意義就在這裡。它不是在證明 Rust 會跑,而是在證明 Rust 能不能在高壓、低容錯的地方活下來。
這也會逼 Mesa 社群重新看待語言選擇。以前很多驅動內部邏輯都被 C 綁死,因為歷史包袱重,大家也習慣了。現在 Rust 能進來,代表維護成本、錯誤類型、審查方式都可能一起變。這種變化不會一夜發生,但方向已經很清楚。
如果 KRAID 後續測試持續過關,下一步就會看它在更多工作負載下的表現。像是不同 shader、不同 Vulkan 場景、不同 Arm 裝置上的穩定性。真正有價值的地方,不是它看起來多新,而是它能不能少出錯、少修補、少讓維護者加班。
放回產業脈絡來看
Mesa 一直是 Linux 圖形生態的核心之一。它連著 OpenGL、Vulkan,也連著一堆硬體廠商的驅動實作。只要 Mesa 的一條路線成熟,後面常常會影響整個 Linux 發行版的圖形體驗。這也是為什麼 KRAID 這種變動值得看。
Arm Mali 的生態也很有代表性。它不是桌機市場的主角,卻在行動裝置、嵌入式與低功耗設備裡很常見。對這類平台來說,驅動穩定性比華麗功能更重要。少一次花屏,少一次 kernel panic,價值都很實在。
我會把這件事解讀成一個訊號:Mesa 願意把 Rust 放到更核心的位置,而且不是試水溫而已。接下來最值得觀察的,不是口號,而是測試覆蓋率、效能數字,還有它能不能順利落進更多 Arm 裝置。開發者如果手上有 Mali v9 以上的板子,現在就可以開始關注這條路線。
接下來該看什麼
接下來最實際的觀察點,是 KRAID 會不會把更多 dEQP 測試吃下來。只要測試面擴大,這條 Rust 編譯器路線就更接近可用狀態。若是效能和穩定性都能站住腳,它就不只是 Mesa 的新選項,而會變成 Arm 圖形驅動的一個常態配置。
我建議開發者先看兩件事。第一,自己手上的 ARM 裝置有沒有用到 Panfrost 或 PanVK。第二,Mesa 發版時有沒有把這條路線往前推。這些資訊比空泛的技術口號有用得多,也更能判斷 Rust 在圖形堆疊裡到底走到哪一步。