後藤弘茂のWeekly海外ニュース
Khronosの次期グラフィックスAPI「Vulkan」
（2015/3/17 12:29）
ローレベルグラフィックスAPIが出揃う
OpenGLなどのAPIを策定するKhronos Groupは、米サンフランシスコで開催されたGDC(Game Developers Conference)に合わせて、新しいグラフィックスAPI「Vulkan(ヴァルカン)」を発表した。Microsoftの「DirectX 12」やAMDの「Mantle」、Appleの「Metal」同様の、ローレベルAPIだ。
ほかの新APIと同様に、従来のグラフィックスAPIの複雑性を廃して、GPUハードウェアによりダイレクトにアクセスできるAPIで、現在のシェーダGPUとマルチコアCPUの性能を最大に引き出せる。ドローコールを大幅に削減することで、ドローコールオーバーヘッドを劇的に下げ、グラフィックス性能を飛躍させることができる。こうした大まかな特徴は、他のローレベルAPIと同じだ。
Khronosは、昨年(2014年)夏に、Vulkanの策定計画を「Next Generation OpenGL Initiative (glNext)」として発表していた。KhronosのAPI策定はかつては時間がかかることが多かったが、今回は異例のスピードで仕上げた。もちろん、グラフィックス業界のローレベルAPIへの急速な傾斜に迅速に対応するためだ。
Vulkan(火山、鍛冶)という名称は、AMDのMantleを、火山性繋がりで連想させる。実際にVulkan策定にはAMDが尽力したという。しかし、MantleとVulkanは同一ではない。カギとなるドライバ層の構造や、メモリの扱いなどに明瞭な違いがあり、Khronosの独自性の強いAPIとなっている。ドライバ層では、新たに中間言語を策定しており、グラフィックスのVulkanとコンピュートのOpenCLを同じコンパイラフロントエンドに吸収できる。
こうした構造からはVulkanの野心的な構想が浮かび上がる。Vulkanは、グラフィックスAPIをローレベルに仕切り直しするというだけでなく、グラフィックスもコンピュートも全て統合できるソフトウェア層の構築を目指している。後述するが、LLVM的な発想を持ち込んでいる点がVulkanの特徴だ。
Mantleに引き続き、Vulkanはゲームエンジンベンダーの支持を得ている。Valveは、自社のゲームエンジン「Source 2」をVulkanに対応させて、自社のゲームクライアントマシン「Steam Machine」で走らせる見込みだ。Vulkanワークグループにはエンジンベンダーが名前を連ねる。
OpenGLがVulkanを正式にアナウンスしたことで、Mantleから始まったローレベルグラフィックスAPIへの変革はついにゴールが見えて来た。構図としては、DirectX 12とVulkanの両クロスプラットフォームグラフィックスAPI系列が対峙するように見える。しかし、今回は、やや状況が異なっている。Vulkanの位置付けに不鮮明な点がある。
まだ見えないAppleとGoogleの動向
昨年のGDCでのDirectX 12の発表には、AMD、NVIDIA、Intel、Qualcommと、GPUハードウェアベンダーが揃って登壇した。しかし、今回のVulkan発表は、GDC内でのセッションはValve Softwareを初めとしたゲームエンジンベンダーを中心としたものだった。GDCに合わせたKhronosのセミナーでは、ハードメーカーも目立ち、AMD以外にNVIDIAやImagination Technologies、ARMなどが登場した。IntelやQualcommもVulkanワーキンググループに入っているので、サポートするとみられる。しかし、DirectX 12の時のようなPCグラフィックスベンダーがこぞってGDCの自社セッションでVulkanをフィーチャするという雰囲気ではない。DirectX 12の時とは、温度差が感じられる。
Vulkanの重要なポイントはOpenGLだけでなく、OpenGL ESのカバーするモバイルや組み込みの領域もカバーする点だ。実際、モバイル系GPUのPowerVRのImagination TechnologiesやMaliのARMは、Vulkanを強くプッシュする。自社の技術セッションでもVulkanを取り上げる。
ローレベルグラフィックスAPIは、Mantleが登場した段階では、ゲーミング向けPCでの性能向上だけが謳われていた。しかし、MicrosoftはDirectX 12で、モバイルのWindows Phone系もカバーすると表明し、AppleはモバイルのiOSでローレベルAPIのMetalを採用した。現在は、ローレベルAPIの潮流は、高性能PCからモバイル/組み込みまでをカバーするという位置付けになっている。
モバイル機器では、APIオーバーヘッドは消費電力を意味する。ローレベルAPIが性能を上げることができるということは、同じ性能なら消費電力を下げることができる。CPUやGPUの効率を上げるローレベルAPIは、実は、バッテリ駆動時間が問題となるモバイル機器にも最適だ。しかし、Vulkanについては、モバイル市場ではAppleとGoogleの動向に疑問がある。
まず、Appleは、iOSのローレベルグラフィックスAPIとしては、Metalを推進している。AppleはVulkanのワーキンググループに名前を連ねるが、MetalとVulkanをどうするのか動向が明確ではない。Googleは、そもそもVulkanのワーキンググループには名前がないので、動向が見えない。
Vulkanの理想的なコースは、OpenGL系とOpenGL ES系を統合した共通のローレベルグラフィックスAPIとなり、PCもモバイルもカバーするというものだ。しかし、モバイルについてはOSの2強であるAppleとGoogleがどうVulkanに対応するかが見えない状況にある。Androidは、チップベンダーが載せてしまえば対応できるが、標準となるかどうかが分からない。
Vulkanに合わせて新しい中間言語SPIR-Vを導入
KhronosはVulkanに合わせて、新しい中間表現「SPIR-V」も発表した。Khronosは、これまでもLLVM(Low Level Virtual Machine)コンパイラインフラストラクチャでサポートされる「SPIR(Standard Portable Intermediate Representation)」を、OpenCLに採用してきた。しかし、今回、Khronosが策定したSPIR-Vは、LLVMでは直接サポートされない。Khronosのコンパイラ層向けの中間表現となっている。
SPIR-Vは、GPUで走らせるプログラム言語をコンパイルするランタイムスタックのフロントエンドとなる中間言語だ。シェーダ言語ソースはSPIR-Vにトランスレートされて、Vulkanのコンパイラ層に渡される。そして、SPIR-Vへのコンパイルは、オフラインで行なわれ、Vulkanランタイムはシェーダソースコードのコンパイルは行なわない。
旧バージョンのSPIRを使う現在のOpenCLは、オープンなコンパイラインフラストラクチャLLVMを利用している。LLVMでは、フロントエンドを通じて各種のプログラミング言語をサポートし、バックエンドが多様なハードウェアをサポートする。コンパイラはスタックに分かれており、ハイレベルコンパイラがSPIRなどの上流の中間言語から、ローレベルの中間言語に変換する。ファイナライザコンパイラがローレベルの中間言語をハードウェアのネイティブ言語へとコンパイルする。HSA(Heterogeneous System Architecture)の場合は、このローレベル中間言語が、GPUのバーチャルISA(Instruction Set Architecture)であるHSAILだ。
LLVMが2フローに分かれた仕組みを取っている利点は拡張性と移植性だ。フロントエンドを拡張することで、多様なプログラミング言語に対応できる。一方、バックエンドを拡張することで多様なハードウェアに対応できる。
従来のOpenCLは、LLVMインフラストラクチャにSPIR 1.2/2.0で落とし込む仕組みになっていた。それに対して、今回のKhronosの発表では、VulkanとOpenCLが、どちらもSPIR-VでKhronosのコンパイラスタックに落とし込まれる形になる。SPIR-Vは、従来のようなバイトコードではなくバイナリの中間言語となっている。
VulkanのコンパイルスタックがLLVMと似た構造になっているかどうかは、まだ分かっていない。しかし、Khronosのこれまでの動きを考えると、LLVMと似た構造になっている可能性は高い。もしそうなら、KhronosはLLVMから離れつつ、LLVM的なコンパイラインフラストラクチャを独自に作るという動きをしていることになる。ある業界関係者は、「声の大きな一部のメンバーの影響力の強いLLVMと距離を置くことで、Khronosにとって最適な言語仕様を作ろうとしたのでは」と語る。もっとも、KhronosはSPIR-VとLLVMの間のコンバータツールもオープンソースにすると発表しており、距離は置きつつ、LLVMの利点もある程度は利用できるようにしようとしている。
