Vulkan 1.4.363、Intel GPUの世代を問い合わせる拡張を追加

Khronos Groupは2026年9月18日、Vulkan仕様のバージョン1.4.363を公開した。VK_INTEL_device_infoという新しいIntel拡張が追加されている。これにより、プログラムはIntelのグラフィックスチップに対して、それがどの世代のハードウェアなのかを直接問い合わせられる。これまで開発者は手書きの対応表から自力で判断するしかなく、推測を誤れば実際の利用者に間違ったコードパスが届いていた。

Vulkanは、ゲームやゲームエンジン、一部の機械学習ツールがグラフィックスカードと対話するために使う、オープンなグラフィックスおよび計算用のインターフェースだ。Khronos Groupはそれを策定する業界団体である。小規模な仕様更新は頻繁に行われ、バージョン番号の末尾がその回数を数えている。

新しい拡張が返す情報

この拡張はVulkanレジストリで709番にあたり、リビジョン1として公開された。VkPhysicalDeviceInfoPropertiesINTELという構造体を1つ追加し、その中に32ビットの符号なし整数を3つ持つ。

フィールド	返す内容
deviceIpVersionArch	グラフィックスアーキテクチャの世代
deviceIpVersionRelease	その世代の中でのリリース
deviceIpVersionRevision	そのリリースのハードウェアリビジョン

ここでの「IP」はintellectual property（知的財産）の略だ。チップの設計者は設計ブロックを多数の製品で使い回す。IPバージョンは、あるチップがどのブロックを含んでいるかを示す。

この構造体はpNextメンバーを通じてVkPhysicalDeviceProperties2につながる。これはVulkanが既存のクエリに追加のフィールドを継ぎ足すときの標準的なやり方だ。すでにデバイスのプロパティを問い合わせているプログラムなら、同じ呼び出しでこの3つの数値を受け取れる。

この拡張の仕様ページは、著者としてIntelのエンジニア2名、Jakub Szymczyk氏とSławomir Grajewski氏を挙げている。日付は2026年9月8日で、これを収録した仕様リリースの10日前にあたる。

Intelがこれを求めた理由

Vulkanはすでに、すべてのグラフィックスデバイスについて数値のdeviceIDを返している。ただしこの番号が示すのは製品であって、その内部の設計ではない。

Phoronixによれば、既存のフィールドは「グラフィックスIPバージョンを公開しないため、アプリケーションやゲームは、デバイスIDとグラフィックスIPバージョンや世代を対応づける手作業の参照表を保守する必要があった」。

こうした参照表には分かりやすい弱点がある。Intelが新製品を出すたびに、表は古くなる。その製品が存在する前に書かれたソフトウェアはそれを認識できない。結果として、安全だが遅い経路に退避するか、誤った経路を選ぶ。ドライバーに直接尋ねれば、この種の不具合はまとめて消える。

これが重要なのは、エンジンがハードウェアの世代ごとに挙動を変えるのが普通だからだ。ある世代でよく動くシェーダーが、次の世代では別の手法を必要とすることがある。

1.4.363のその他の変更

今回のリリースは、新しい拡張と並ぶ通常の仕様更新でもある。Phoronixは、仕様の各所に対する明確化といくつかの修正が含まれると伝えている。

変更の1つはDMA-BUF外部メモリに関するものだ。DMA-BUFは、メモリの領域をコピーせずにドライバー間で共有するためのLinuxの仕組みである。今回の更新はこれにマルチインスタンスの検証規則を追加し、VkMemoryAllocateInfoとVkMemoryGetFdInfoKHRの構造体に影響する。検証規則とは、プログラムが満たすべき条件のことだ。開発者がテスト中に動かす検証レイヤーがそれを確認する。

仕様のタグ自体は9月18日にKhronosのVulkan-Docsリポジトリで公開された。Phoronixはその2日後にリリースを報じている。

開発者にとっての意味

新しいクエリを、まだガードなしで呼んではいけない。VK_INTEL_device_infoはベンダー拡張であり、Intelのドライバーにしか存在しない。しかも9月の仕様を取り込んだ新しいドライバーに限られる。構造体を読む前にデバイスがこの拡張を提示しているか確認し、いま使っている参照表はフォールバックとして残しておくこと。

そのフォールバックは長く使うつもりでいたほうがいい。仕様のリリースは展開の始まりであって、終わりではない。この拡張はLinuxのMesaのIntelドライバーと、Intel自身のWindowsドライバーに届く必要がある。そこからディストリビューションの更新やドライバーのダウンロードを経て、ようやく利用者に届く。古いドライバーの利用者は、引き続き何も返さない。

リビジョン1である点にも注意したい。ベンダー拡張の初期リビジョンは、定着する前に変わることがある。フィールドが動かないと決めつけず、リビジョン番号を読むこと。

導入コストは低い。この構造体は、多くのエンジンが起動時にすでに行っているプロパティのクエリにつながる。往復が増えることはなく、フレームごとの処理も増えない。もし現在のコードがIntelのハードウェア世代で分岐しているなら、これは手作業で保守してきた表を1つ削れる小さな変更だ。

最初のドライバー側の実装は、Mesaのコミット履歴で追うとよい。仕様のリリースではなく、そこが実機でこのクエリが答え始める地点だ。Intelは今月、Ubuntu 26.04対応のLinux向けNPUドライバー1.38を出荷しており、ドライバーの機能は同じ周期でディストリビューションに届く傾向がある。