Linux

Mesa 26.1 RADV、VK_EXT_descriptor_heapでSteam Play加速

DXVKとVKD3D-Protonが長年抱えてきた「D3D12をVulkanで再現するコスト」という構造的問題に、AMDのRADVドライバがついに正面から手を打った。Mesa 26.1で統合されたのは、Windowsゲームの描画効率を根本から変えうる拡張機能だ。

情報の灯台

2026年4月14日

DXVKとVKD3D-Protonが長年抱えてきた「D3D12をVulkanで再現するコスト」という構造的問題に、AMDのRADV ドライバがついに正面から手を打った。Mesa 26.1で統合されたのは、Windows ゲームの描画効率を根本から変えうる拡張機能だ。

2か月の沈黙を破って、ようやくmainへ

Phoronixが2026年4月14日に報じたところによれば、Mesa Radeon Vulkan ドライバ「RADV」がVK_EXT_descriptor_heapのサポートをMesa 26.1に統合した。作業を担ったのは、Valveのオープンソースグラフィックスチームに所属し、RADVへの主要コントリビュータでもあるSamuel Pitoiset氏だ。

マージリクエストは2か月前から存在し、レビューを経て今日ようやくmainブランチに取り込まれた。2か月の滞留は怠慢の結果ではない。この拡張機能がいかに広範囲を書き換えるかを示している。

VK_EXT_descriptor_heapはVulkan 1.4.340で2026年1月に導入されたばかりの新拡張で、NVIDIA、AMD、Arm、任天堂、Valve、Googleなど多数のベンダーが策定に関わった。記述子（descriptor）と、その格納に使われるメモリそのものを明示的に管理できるようにするのが狙いで、前身のVK_EXT_descriptor_bufferで露呈した設計上の粗を一通り洗い直した形になる。

なぜDXVKとVKD3D-Protonが欲しがっていたのか

D3D12とVulkanのあいだには、描画リソースの扱い方に根本的な断絶がある。D3D12はアプリケーション側が「ディスクリプタヒープ」という巨大なメモリ塊を直接管理するモデルだが、従来のVulkanは各リソースを個別のAPIオブジェクトとして扱う設計だった。

vkd3d-protonではD3D12をVulkan上の層状実装として作っており、ネイティブドライバと性能で肩を並べようとするとき、D3D12のディスクリプタモデルをVulkanで再現する作業はずっと悩みの種だった。

VKD3D-ProtonチームがVK_EXT_descriptor_buffer策定時に書き残したこの一文が、構造的な苦境を端的に物語っている。

VKD3D-Protonは内部で100万エントリ規模の固定サイズディスクリプタセットを7個確保し、その上でD3D12の振る舞いをエミュレートしている。メモリも無駄なら、ディスクリプタのコピーのたびにAPIコールが挟まるのも無駄だ。

ディスクリプタヒープ拡張が入ると、この層が大幅に薄くなる。ヒープは事実上ただのバッファとして扱え、ディスクリプタのコピーは memcpy() 一発 で済む。API呼び出しのオーバーヘッドが消え、D3D12アプリケーションがWindows上でやっているのと同じ振る舞いに、Linux側もようやく近づく。

これは「数フレーム速くなる」という話ではない。翻訳コスト自体が縮むという話だ。影響範囲はSteam DeckからデスクトップのRDNA4まで、RADVが走るすべての環境に及ぶ。

NVIDIAはすでに先行、AMDは2番目

デフォルト有効にするには拡張の規模が大きすぎるし、バグも予想される。テストカバレッジが十分ではないからだ。安定したら、今後1〜2回のMesaリリースでデフォルト有効にする。

Pitoiset氏はマージリクエストにそう書き添えている。ドライバ開発者らしい、地に足の着いた慎重さだ。

現時点でMesa 26.1-develを使う場合、環境変数 RADV_EXPERIMENTAL=heap を設定することで機能を有効化できる。人柱勢と開発者向けの門が開いた状態、と言っていい。

NVIDIA側は一足先に動いていた。R595 LinuxドライバでVK_EXT_descriptor_heapのサポートをすでに実装している。興味深いのは、NVIDIAの純正ドライバ上でこの拡張を有効にしたVKD3D-Protonの検証ブランチが、Blackwell世代のGPUで起きていたXid 109ハードクラッシュや、特定タイトルのロード時フリーズを回避できたという報告が複数上がっていることだ。つまりこの拡張は、単なる速度改善ではなく「そもそも動かなかったものが動く」カテゴリの話でもある。

DXVKは先行、VKD3D-Protonはまだドラフト

興味深いのは、クライアント側の対応速度だ。DXVKはすでに2026年2月の段階で VK_EXT_descriptor_heap を利用する新しいディスクリプタ管理コードをマージしている。dxvk.enableDescriptorHeap を有効にすると新経路が使われる設計で、実験的に試せる状態が既にある。

一方でVKD3D-Proton本体の実装はHans-Kristian Arntzen氏によるプロトタイプPR #2805がまだドラフト扱いで、プロダクション化には時間がかかる。既存のdescriptor bufferパスとヒープパスを 共存させる必要 があり、これはArntzen氏の言葉を借りれば「華々しいほどの混沌」になるからだ。