MesaがVulkan共通基盤Shiva開発へ 2年で結実狙う

Mesaプロジェクトにおいて、Vulkan駆動程序向けの新たな共通基盤「Shiva」の開発が始動した。 Phoronix の Michael Larabel の報道では、2026年9月28日にカナダ・トロントで開催されたXDC 2026において、CollaboraのFaith Ekstrandが構想を発表したと伝えた。 Shivaは、OpenGL駆動程序向けのGallium3Dに相当する枠組みをVulkan向けに提供する試みである。 実現までには時間を要するものの、符号共有の促進と開発体験の改善が期待されている。

MesaにはIntelのANVやAMDのRADV、NVIDIA向けNVK、Arm Mali向けPanVKなど複数のVulkan駆動程序が存在する。 各駆動程序は独自の最適化を進める一方で、拡張機能への対応や変換処理、補助処理の実装が重複している。 Vulkanの仕様拡張は継続し、検証層や妥当性確認の負担も増大している。 結果として、開発者間の知識共有が難しくなり、新規参入の障壁が高まっている。

今回の提案は、現状の分散開発を維持したまま個別対応を続けることが困難になったという認識に基づく。 Ekstrandは、Vulkanの実装負担が構造的に増していると指摘した。 発表資料では、初期のVulkanと現在のVulkanの隔たりが強調された。

– Vulkan was fun and easy to implement in 2016…– Vulkan in 2026 is full of backwards compatibility cruft.

同氏は、今後の仕様拡張により実装がさらに困難になるとの見通しを示した。 この発言は、単なる感想というより設計判断の前提である。 後方互換性の維持と新機能の追加が並行することで、駆動程序側の分岐処理が増え続けている。

Vulkan肥大化と開発の限界

Vulkanは2016年の登場当初、明示的な制御と薄い抽象化を特徴とした。 駆動程序の処理を単純化し、応用側に責任を持たせる設計が評価された。 しかし10年を経て、拡張機能の数は大幅に増加した。 レイトレーシングや映像符号化、機械学習向けの協調行列など対象領域が拡大している。

Vulkan Videoエンコード、Intel Alchemist GPUで復活が示すように、映像処理系の実装も駆動程序の作業範囲に含まれる。 メモリ割り当てや同期、記述子管理に関する補助機構も複雑化している。 各販売会社のGPU構造の差異を吸収する処理は、個別の駆動程序に重くのしかかる。 同一機能に対する変換処理が複数の駆動程序で重複して維持されている。

Ekstrandは、現状のままでは断片化が進むと分析した。 共通の変換処理や補助処理が整理されず、各駆動程序に分散している。 不具合修正や仕様追従が個別対応となり、全体の保守費用が増大している。 この構造は、新しいGPUへの対応速度にも影響する。

Gallium3Dの実績とVulkanへの応用

Gallium3Dは、MesaにおけるOpenGL駆動程序の共通基盤として定着した。 状態管理や着色器の翻訳、描画処理の抽象化を中間層に集約した。 GPU固有の符号は後段に限定され、前面の状態追跡は共有された。 この分離により、新規駆動程序の開発期間は短縮された。

Gallium3Dの導入後、複数のOpenGL駆動程序が共通機構を利用した。 不具合修正が中間層に集約され、全体の品質が安定した。 開発者はGPU固有の最適化に集中できるようになった。 保守対象の重複が減り、検証作業も効率化された。

Shivaは、この成功をVulkan領域に適用する構想である。 ただし対象となるのはVulkan駆動程序であり、OpenGLではない。 OpenGL向けの状態機械をそのまま持ち込むものではない。 Vulkanの明示的な資源管理と拡張機構に適した抽象化が求められる。

発表では「Vulkan向けのGallium3D」という表現が用いられた。 既存のMesa開発者が理解しやすい説明である。 目的は符号の共通化と開発手順の統一にある。 特定の販売会社やGPU構造に依存しない設計が前提となる。

Shivaが担う抽象化の役割とは

Shivaは、Vulkanの応用界面と駆動程序の間に置かれる基盤である。 MesaのVulkan駆動程序は、Vulkan仕様に直接対応するのではなくShivaの界面を対象とする。 Shiva側が後方互換性の吸収や拡張機能の整理を担う。 駆動程序側はGPU固有の命令生成や資源操作に集中する。

この分離により、仕様追従の作業は基盤側に集約される。 各駆動程序が個別に互換処理を抱える必要がなくなる。 変換処理や補助処理の重複は削減される。 検証すべき経路が整理され、試験の再利用性が高まる。

Ekstrandは、Shivaを枠組みや基盤として位置付けた。 単一の書庫にとどまらず、駆動程序開発のための構造である。 界面設計や資源抽象化、拡張管理の指針を含む。 開発手順の標準化も視野に入っている。

設計上の要点は、抽象化の粒度にある。 粒度が粗すぎればGPU固有の最適化を阻害する。 細かすぎれば共通化の効果が薄れる。 性能と共有性の均衡を保つ界面設計が求められる。

適用対象はNouveauとPanfrostから開始

開発は近い将来に開始される計画である。 初期の適用対象は、NouveauとArm Mali向けPanfrostとされた。 NouveauはNVIDIA向けの開放型駆動程序基盤である。 PanfrostはArm Mali向けの開放型駆動程序基盤である。

両者は既にMesa内で開発が進められてきた。 GPU構造が異なり、抽象化の検証に適している。 異なる販売会社の構造で有効性を確かめられる。 共通機構の過不足を早期に発見できる。

利用者向けの成果が出るまで約2年と見積もられた。 基盤設計、既存駆動程序の移行、検証に時間を要する。 短期間で置き換わるものではない。 段階的な移行と評価が繰り返される見通しである。

XDC 2026では幻灯資料と記録映像が公開された。 設計の詳細は今後の議論で具体化する。 界面仕様や移行手順は未確定の部分が多い。 開発者会議や投稿記録での議論が続く見通しである。

Rust対応を見据えた設計思想

Shivaは将来のRustによる駆動程序開発も視野に入れている。 MesaではRustによる駆動程序の試行が進んでいる。 メモリ安全性や並行処理の記述性が注目されている。 既存のC言語資産との共存が課題である。

基盤側で資源管理や寿命管理を整理できれば、Rustとの親和性が高まる。 界面が明確であれば言語間の結合部を限定できる。 検証機構の共有も容易になる。 新規開発者の参入障壁も低下する。

ただしRust対応は副次的な効果である。 主目的はVulkan駆動程序の断片化の解消にある。 言語中立的な界面設計が重要になる。 特定言語に依存しない抽象化が求められる。

Mesa全体の保守体制にも影響する。 共通基盤が安定すれば、拡張対応の重複作業は減る。 各駆動程序の保守担当者は最適化に注力できる。 長期的な持続可能性の向上につながる可能性がある。

編集部の見解

今後3〜6か月では、Shivaの界面設計をめぐる議論がMesa開発の中心になると見る。既存駆動程序の保守負担はすぐには変わらないが、共通化対象の洗い出しは進むと評価する。拡張機能への対応方針が整理されれば、重複実装の抑制につながる可能性がある。

1〜3年では、駆動程序間の品質格差が縮小すると見る。Rustによる駆動程序開発の敷居が下がれば、保守参加者の層が広がると評価する。検証基盤の共有が進めば、長期的な保守費用の低減につながる可能性がある。

抽象化層の肥大化をどう抑えるかが論点になると見る。Gallium3Dの経験を生かせるかは、境界設計の厳密さにかかっていると評価する。性能と保守性のどちらを優先すべきか、現場の判断が問われているのではないだろうか。

参考

• 「“Shiva” Being Developed For Mesa Vulkan Drivers, Akin To Gallium3D」, by Michael Larabel — Phoronix, 2026-09-29T00:32:08.000Z (ARR)
• 元記事URL: https://www.phoronix.com/news/Mesa-Shiva-For-Vulkan