Intel ANVが圧縮メモリ型の提示を既定化、DXVKのDX11トレースで最大5.26％改善

MesaのIntel向けVulkanドライバー「ANV」は、一般のVulkanバッファーに圧縮メモリ型を提示する範囲を広げた。8月18日にマージされた2本のコミットにより、当初はDXVK向けの設定として追加された機能が、通常のバッファー経路の既定動作へ移った。Mesaの性能CIでは、DXVKを通すDirect3D 11トレースでBattlemageが最大5.26％、Panther Lakeが最大4.85％速くなったという。

数字だけを見ると、Intel GPU向けの「フレームバッファー圧縮」が有効になったように受け取られかねない。しかし、今回ANVが扱うのは表示用のフレームバッファーではない。Vulkanアプリケーションがレンダリング処理で使うVkBufferに対し、CCS（Color Control Surface）用のAUXメタデータを伴う圧縮メモリ型を選べるようにする変更である。Linuxカーネルの表示機能であるFBCとは、対象も制御する層も違う。

DXVKは、Wine環境でDirect3D 8、9、10、11をVulkanへ変換するレイヤーだ。今回の測定値はゲームの一般的な性能保証ではなく、Mesa performance CIのDX11トレースで4回ずつ実施した結果である。それでも、ドライバーがアプリケーションにどのメモリ型を提示するかという低い層の選択が、翻訳レイヤー経由の性能にまで影響し得ることを示す材料にはなる。

DXVK向け設定からANVの既定経路へ

最初のコミットac512a9cは、ANVの既定値ファイル00-anv-defaults.confにDXVKエンジン向けのanv_enable_buffer_comp=trueを加えた。この段階では、DXVKで走るアプリケーションに限って、圧縮バッファーを使えるようにするプロファイルだった。以前からSource2とvkd3d-protonには似た例外が置かれており、vkd3d-protonはProtonでDirect3D 12をVulkanへ実装するプロジェクトである。

続くab84cbe8は、DXVKのプロファイルをさらに増やす方向を選ばなかった。anv_enable_buffer_compというdrirc設定自体を削除し、一般バッファーの許可メモリ型へ圧縮メモリ型を常時加えるようコードを改めた。つまり変更後の範囲は、Source2、DXVK、vkd3d-protonの個別設定に閉じない。アプリケーション側の割り当てが圧縮型を選べるなら、ANVの通常経路でその候補が見える。

この二段階は、DXVK専用の最適化を追加しただけ、という理解とは異なる。コミットメッセージは、わずかに遅くなったトレースを救うために個別の例外を残すより、設定の複雑さを減らして全体へ広げる判断を記している。負方向の値は後述するように0.6％未満であり、開発側はその差をアプリケーションごとの分岐を維持する根拠とはみなさなかったようだ。

取り込み先はMesa 26.3の開発系である。Mesaの公開カレンダーでは26.3.0-rc1を2026年10月14日、rc4または最終版を11月4日に予定する。ただしこれはMesa側の予定であり、個々のLinuxディストリビューションのパッケージに入る日付までは決めない。

VkBufferへ提示するメモリ型が増える

Vulkanでは、アプリケーションがバッファーを作成すると、ドライバーはVkMemoryRequirements.memoryTypeBitsで結び付け可能なメモリ型を返す。アプリケーション、またはDXVKのような変換レイヤーは、そのビット集合に含まれる型からメモリを割り当てる。今回の変更は、すべてのバッファーを圧縮状態へ強制する命令ではない。圧縮メモリ型を、選択肢として見える場所に加える実装である。

変更前のanv_buffer.cでは、一般バッファーに既定のメモリ型とcompressed_mem_typesの和集合を返すのは、enable_buffer_compが真のときだけだった。変更後は、その条件が取り払われた。保護メモリやディスクリプターバッファーなど、専用のdynamic-visible heapを必要とする用途は別分岐で扱うため、圧縮型があらゆる用途へ無差別に提示されるわけでもない。

ANV内部ではANV_BO_ALLOC_COMPRESSEDが「Xe2以降でのみ対応する圧縮バッファー」として定義されている。ここでの圧縮は、CCS/AUXメタデータを伴うGPUメモリの経路であり、対象は主にレンダリング中のバッファーである。ANVのコードコメントは、圧縮メモリ型が画像には概して有利でも、バッファーでは不利になり得ると説明している。圧縮・展開やメタデータ管理のコスト、アクセスパターンとの相性があるためだ。

一方、LinuxカーネルのIntel display FBCは、ディスプレイが走査するフレームバッファーの帯域と電力を抑える機能である。i915がstolen memoryと呼ばれる事前確保領域を予約し、ハードウェアが圧縮と展開を管理するため、ユーザー空間からは透明に動く。ANVの変更と共通するのは帯域削減を狙える点にすぎない。前者はカーネルの表示パイプライン、後者はユーザー空間のVulkanドライバーがVkBufferへ返すメモリ型であり、性能が現れる場所も同じではない。

最大5.26％と約0.5％低下が同居する

最初のコミットに記載されたMesa performance CIの数値は次の通りである。いずれもDXVK経由のDX11トレースを4回測定した結果だが、解像度と画質設定はコミット本文で明らかにされていない。CPU、メモリ構成、比較元ドライバー、ばらつきも同様に不明である。

同じ圧縮メモリ型の選択肢を増やしても、性能差はタイトルによって大きく異なる。Shadow of the Tomb Raiderでは両GPUで4％台後半から5％台の改善が出た一方、God of WarとMount & Blade II: Bannerlordは約0.5％下がった。プラス側でも0.50％、0.56％のような小さい値があり、分散が非公開のため、これらを確実な体感差として読むことはできない。

転送量を減らせる場面で圧縮型が有利になる、という説明は機構としては整合する。Panther Lakeは統合GPUとしてCPUとシステムメモリ帯域を共有するため、帯域を節約する価値が大きく見える局面もあり得る。しかし、今回の最大値はPanther Lakeの4.85％とBattlemageの5.26％で近い。dGPUかiGPUかという分類だけで効果を説明する材料にはならない。

さらに、コミットは実測したメモリ帯域、圧縮率、圧縮されたバッファー種別を公開していない。したがって「帯域が減ったから高速化した」と因果を確定することはできない。測定値は、各トレースのボトルネックとメモリアロケーションの選択が組み合わさった結果として受け取るべきだろう。

CTSの無回帰は実ゲームの結論ではない

2本目のコミットは、Vulkan Conformance Test Suite（CTS）で回帰が観測されなかったと記す。これは、許可するメモリ型を広げてもVulkanの仕様適合性試験では問題が出なかった、という意味で重要だ。drircスイッチを消して既定経路へ移す前提として、少なくともAPIの適合性を確認したことになる。

ただしCTSは、各ゲームの描画品質、長時間プレイ時の安定性、性能を網羅的に保証する試験ではない。今回公開された性能値には、1％ lowと0.1％ lowがない。フレームタイム分布、消費電力、VRAM使用量も公開されていない。DX11トレースはDXVKが最も直接関わる条件であり、他のAPI、他のゲームエンジン、Alchemist以前のIntel GPUへそのまま広げることもできない。コード上の圧縮バッファー対応はXe2以降とされる。

Mesa 26.3が実際に配布されてからは、平均フレームレートに加えて、圧縮型を選んだバッファーの種類とフレームタイムを対応付けた検証が必要になる。そこで初めて、最大5.26％という上限側の値がどの負荷に再現し、約0.5％の後退が測定の揺らぎなのか相性なのかを切り分けられる。ANVが増やしたのは圧縮の強制ではなく、アプリケーションに渡す選択肢である。その選択が現実のゲームでどう使われるかが、次の判断材料になる。