Vulkanを一つのサブシステムずつ簡素化する

2026年2月10日原文(khronos.org)

概要

Vulkan® APIの進化には 拡張機能 （Extensions）が重要な役割
拡張機能の増加による “Extension Explosion Problem” の課題
部分的な改善ではなく サブシステムの丸ごと置き換え が新たなアプローチ
VK_EXT_descriptor_heap はその具体例であり、広範な業界の協力で開発
コミュニティからの フィードバックを歓迎 し、今後のAPI改善に活用

Vulkan API進化のための拡張機能活用

Vulkan®ワーキンググループ はAPIの機能追加や仕様のギャップ解消を目的に 拡張機能 を活用
拡張機能により 新機能 を迅速に開発者へ提供
ベンダー独自の機能公開や コミュニティのフィードバック収集 が可能
コア仕様に盛り込む前に実践的な検証と改善が行える体制
OpenGL®/ES™ 時代から続く拡張機能増加による複雑化問題

Extension Explosion Problem（拡張機能爆発問題）

拡張機能の増加による 利用方法の複雑化 と分かりづらさ
どの機能が常に利用可能か、最適な手法は何かといった判断の困難化
複数の拡張機能が 連鎖的に絡み合う ことで開発者の負担増大
OpenGL® からVulkan®に移行した際の“クリーンスレート”も10年で再び同様の問題発生
APIの抜本的な再設計は非現実的なため、 新たな拡張機能によるサブシステム置き換え が提案

サブシステム置き換えの新手法

部分的な拡張や改善 ではなく、APIサブシステム全体を 新拡張機能で丸ごと置き換え る手法
新方式では 過去のAPIとの互換や依存を断ち切る 設計
VK_EXT_descriptor_heap は既存のディスクリプタセットサブシステムを完全に置き換える初の試み
ディスクリプタが 単なるデータ・メモリ として扱える柔軟な設計
コンソール機に近い操作感 を提供し、ポータブルAPIの制約を軽減

VK_EXT_descriptor_heapの特徴と開発経緯

過去の VK_EXT_descriptor_buffer の経験と課題を踏まえた再設計
既存のディスクリプタセットAPIやレイアウト、プッシュディスクリプタ等との 非互換性 を明示
広範な業界の協力と Vulkan Working Group全体の知見結集
3年以上かけて設計・改良 を重ね、品質と実用性を両立
現時点では EXT拡張 として提供、将来的な コア（KHR）化 を視野

コミュニティフィードバックと今後の展望

EXT拡張 の段階で幅広い開発者からのフィードバックを募集
仕様の大幅な変更予定はないが、 KHR化時に移行しやすい設計
9ヶ月以内 のフィードバックが仕様完成への重要なインプット
他の機能要望も DiscordやGitHub で積極的に受付
サブシステム置き換え手法を 今後のAPI刷新 にも適用予定

今後のVulkan APIと開発者への呼びかけ

開発者ニーズ中心 のロードマップ策定と優先順位付け
エコシステム全体、ベンダーのロードマップ、将来のハード・ソフト動向も考慮
使いやすく、楽しいAPI への進化を最優先
サブシステム置き換えによる 抜本的な改善 を今後も推進
フィードバックや意見 を積極的に求める姿勢

Hackerたちの意見

この変更、めっちゃ楽しんでる！レンダーパスからダイナミックレンダリングに移行したら、コードがすごくシンプルになった。新しい機能は、既存のバインドレスレンダリングと比べてどうなんだろう？リンクされた動画で言ってた「OpenCLとの機能の互換性」が一番楽しみだな。

└

オプションの「ルートシグネチャ」を設定すれば、既存のバインドレスシェーダーでもデスクリプタヒープが使えるよ。ただ、新しいGLSL/SPIR-V機能（またはSlang）を使うようにシェーダーを変更する方が簡単そうだね（できるなら）。ルートシグネチャを全く指定しない方がいいし、複雑で冗長だからね。デスクリプタヒープはセットアップコードをかなり減らしてくれるし、パイプラインレイアウトがなくなったから、始めるのに必要なコードの3分の1を削減できるよ。ダイナミックレンダリングと同じくらいの効果だね。

個人的には、どこでもプッシュデスクリプタを使うように切り替えたよ。デスクトップでは、実際の制限が高いから、うまくいくし、OpenGLみたいな即時モードAPIが使えるんだ。

└

シンプルなユースケースや新しいプロジェクトを始めるには、これが正しい方法だね。

Vulkanを使いたいんだけど、OpenCLから移行するのがめっちゃ大変で、いろんな問題があって安全に扱わなきゃいけないんだ。OpenCLのワークロードからは出てこない問題ばかり。みんなOpenCLは非推奨だって言うけど（確かにそうだけど、2026年でもバリバリ動いてるのも事実）、自分のやってることに正当性を持たせるための良い公式のOpenCLからVulkanへのラッパーがないんだよね。

少なくとも、拡張機能のスパゲッティを修正しようとしてるのは評価できる。もうOpenGLよりひどい状態だしね。さらに、これらの修正のほとんどはAndroidには入ってこないし、OpenGL ESから移行を拒否する人が多かった後に、Java/Kotlin用のWebGPUがやっと出てきたところだし、運が良くないカードは新しいドライバーも出ないしね。それでも、今やらないよりはマシだよね。[0] - https://developer.android.com/jetpack/androidx/releases/webg...

└

さらに、これらの修正のほとんどはAndroidには来ないよ何言ってるの？もちろんAndroidにも来るよ。

└

変な意見だね。WebGPUがAndroidXライブラリだって気づいてる？つまり、WebGPU APIのサポートはそのライブラリを通じてアプリに組み込まれていて、システムのVulkanやOpenGL ES APIの上で動いてるってことだよ。君はGoogleかAndroidのOEMで働いてるの？そうじゃないなら、AndroidがVulkan APIのサポートを更新しなくなるって主張する根拠はないよ。

└

ゲーム開発者として言わせてもらうと、AndroidでVulkanをサポートしないでOpenGL ESにこだわるのは安全策だと思う。Vulkanでバグが出るデバイスは常にあるからね。誰もその変なベンダーのために workaround を見つけるのは嫌だよ。

Vulkanの主な問題は、プログラミングモデルや機能の不足じゃないんだ。Khronosがそれに取り組んでるからね。問題はカバレッジとアップデートの配布なんだ。めちゃくちゃばらばら！一般的なソフトウェア（Zedみたいな）を開発してると、ダイナミックレンダリングみたいな基本的なことですら均一にサポートされてるとは限らない。古いドライバーを使ってる変なシステム（Ubuntu 22 LTSを見てる）、ハードウェアベンダーが放置して使えなくすること、もちろんドライバーバグも…新しいデスクリプタヒープやバッファ機能に頼れるようになる頃には、もっと白髪が増えてるだろうし、他にもいろいろあるだろうな。

└

正直言って、時代に合わないGPUベンダーはさっさと見限るべきだよね。長いこと彼らに合わせてたら、適応する理由がなくなっちゃうから。

└

Ubuntu LTS だから、僕は新しいLinuxユーザーにはUbuntuをあまり勧めないようにしてるんだ。機能面で遅れをとってるからね。今や企業向けOSになっちゃって、耐久性が機能性よりも重要視されてるし、パワーユーザー（Zedみたいな人）にはあまり向いてないよ。

Hacker Newsで議論の続きを見る

ハクソク