［GTC 2018］Khronosが語る「Vulkan 1.1」。VR＆AR向けAPI「OpenXR」の最新動向も

　GTC 2018で，OpenGLやVulkanといったAPIの標準化を担当する業界団体Khronos Group（以下 Khronos）は，同グループが手がけるオープンスタンダードAPIに関するセッションを多数開催していた。その内訳はグラフィックス向けの「Vulkan」や仮想現実（Virtual Reality，以下 VR）および拡張現実（Augmented Reality，以下 AR）分野向けの「OpenXR」，並列コンピューティング向けとなる「OpenCL」などだ。

Neil Trevett氏（Vice President Developer Ecosystem，NVIDIA）。今回はKhronosのPresidentとして壇上に立った

　それらすべてを網羅して紹介するのはさすがに無理なのだが，幸いなことにGTC 2018では，Khronosの代表を務めるNVIDIAのNeil Trevettニール・トレヴェット）氏が自らオープンスタンダードAPI群の最新動向をまとめてくれたので，今回はそんな氏によるセッション「Khronos Standards Update: Vulkan, glTF, OpenCL and OpenXR for Cross-Platform VR/AR」の内容をレポートしたい。

Vulkan：Nintendo Switchが対応。iOSアプリも開発可能に

Vulkan 1.0のシンボルマーク

　まずはVulkanの話題から始めよう。
　ローレベルグラフィックスAPIのVulkanは，肥大化しすぎてしまったOpenGLに対する，もう1つの選択肢として登場したものだ。AMDが開発したグラフィックスAPI「Mantle」を下敷きとしてバージョン1.0が登場したのは2016年2月のこと。Windowsだけでなく，LinuxやAndroidといったプラットフォームでも広く採用されたが，バージョンは2年以上も据え置きのままだった。

　しかし，KhronosもVulkanのアップデートを怠っていたわけではない。北米時間2018年3月7日にKhronosは新バージョンとなる「Vulkan 1.1」をリリースしたのだ。
　バージョン番号がコンマ1増えただけということからも想像が付くとおり，Vulkan 1.1はマイナーアップデートという扱いである。しかし，「バージョン1.0のリリースから2年の間にグラフィックス業界のキープレイヤーから得たさまざまなフィードバックを受け，改良を施したもの」ということで，注目度は高い。

Vulkan初のマイナーアップデート版となるVulkan 1.1が登場した

　Vulkan 1.1の新機能を説明する前に，Trevett氏は，Vulkan 1.0のリリース後に生じた業界の反応をセッションで簡単に振り返っている。
　いわく，大きな採用事例としてはNintend Switch（以下，Switch）が挙げられるそうだ。「詳細は明らかにできない」（Trevett氏）ながらも，広く開発者を呼び込むため，Switchで任天堂は独自のフレームワークによる開発キットだけでなく，Vulkanベースの開発環境も整備を進めているという。

Vulkan 1.0に対応した企業やプラットフォーム，ゲームエンジンの一覧

　現在のところ，Vulkanの普及が最も進んでいるのはAndroidベースのスマートフォン向けゲーム開発だそうだ。さまざまなゲームスタジオが独自にVulkanを採用しているのではなく，「Unity」や「Unreal Engine 4」といったゲームエンジンがVulkanをサポートしているのが効いているとTrevett氏は振り返っていた。
　なお，PCにおいてはこれまでも積極的にOpenGLをサポートしてきたid SoftwareとValveの存在感が依然として目立っている。

多数のスマートフォン向けゲームがVulkanベースとなる。「ゲームエンジンのVulkan対応が大きく効いた」とはTrevett氏の弁

id softwareの「id Tech Engine 6」やValveの「Source 2」は，Vulkanに対応済み。これらのエンジンを採用するタイトルではVulkanベースの描画モードを備えるものが増えている

　Vulkanがらみでとくに大きな反響を巻き起こしたものとしてTrevett氏が挙げていたのは，「MoltenVK」のロイヤリティフリーなオープンソース化だ。
　MoltenVKとは，Vulkanベースで開発したグラフィックスプログラムを，iOSやmacOSといったAppleのプラットフォームへ移植するための開発ツールである。
　Apple系プラットフォームにおけるグラフィックスAPIは，OpenGLが標準として使われていた。しかしAppleは，ローレベルのグラフィックスAPIにおいて，OpenGLの流れを汲むVulkanではなく，独自の「Metal」を2014年に導入したという経緯がある（関連記事）。MoltenVKは，VulkanベースのグラフィックスエンジンをMetalベースへ移植するための支援ツールなので，それがロイヤリティフリーのオープンソース化を果たしたのは，インパクトのあるニュースなのだ。

AppleのプラットフォームはローレベルグラフィックスAPIとして独自のMetalを推進しているが，MoltenVKを使うと，VulkanベースのアプリケーションをMetalへと容易に移植できるという

　Trevett氏によれば「OpenGLネイティブに開発したアプリよりも，MoltenVKを利用して移植したほうが，1.5倍も高い性能が得られる」とのこと。macOS版の「Dota 2」は，まさにMoltenVKを用いて移植したものなのだそうだ。

同一GPUで，Dota 2のOpenGL版と，MoltenVKでMetalに移植したVulkan版のフレームレートを比較したというスライド。いずれもVulkan版が優れている

Vulkan 1.1ではサブグループ処理への対応が目玉

　以上を踏まえてVulkan 1.1だが，言うまでもなく進化のポイントは多岐にわたるため，今回は，

• Subgroup Operations
• Multiview
• Device Groups
• Cross-process and Cross-API sharing
• Advanced Compute Functionality
• HLSL Support
• YCbCr Support

の7項目を手短に紹介してみたいと思う。ちなみに，記憶力のいい読者は憶えているかもしれないが，Subgroup Operations（サブグループ処理）以外は，Vulkan 1.0時代に「Extension」（メーカー独自の拡張機能）として提供されていたものを標準化して取り入れたものとなる。
　基本的なことを振り返っておくと，今日（こんにち）におけるNVIDIAのGPUアーキテクチャでは32個のデータを1単位データスレッド「Warp」，AMDのGPUアーキテクチャでは64個のデータを1単位のデータスレッド「Wavefront」として管理している。
　サブグループ処理というのは，WarpやWavefrontといったデータスレッドに収まる範囲で，（外部の）共有メモリなどに頼ることなしにスレッド同士が直接データのやりとりを行えるような仕組みを定義することを指す。Vulkan自体は特定のGPUアーキテクチャに依存するわけではないので，サブグループ処理の対象となるデータスレッドのサイズは32個でも64個でも構わない――チュートリアルを読む限り，1，8，16，32，64，128個に対応する――とのことだ。

サブグループ処理の例。なお，サブグループ処理は，GPGPU的なCompute Shaderだけでなく，グラフィックス用のプログラマブルシェーダでも利用できるそうだ

　次にMultiviewは，NVIDIAがPascal世代のGPU向け機能として提供していた「Simultaneous Multi-Projection」を，Vulkanに取り込んだものである。Multiviewでは，1回のレンダリングパスで複数視点からのレンダリングを行えるので，VR HMDにおける左右の目に合わせた映像の描画や，直交する6方向に視界を設定したキューブマップテクスチャのレンダリングなどに利用できると，Trevett氏は説明していた。

　次のDevice Groupsは，DirectX 12で先行導入された「システム上にある複数のGPUを個別に活用する機能」をVulkanでも実現するものだ。
　これまでのマルチGPUソリューションと言えば，NVIDIAのSLIやAMDのCrossFireのような，「複数あるGPUをあたかも1基のGPUであるかのように見せるAPI」を用意しておいて，アプリケーションがそのAPIを利用すれば複数のGPUを活用できるというスタイルが主流だった。それに対してDevice Groups機能は，アプリケーションから複数のGPUを個別に，しかも直接利用できるようにするものである。
　Device Groups機能を使えば，アプリケーション側から「GPU1にはこの仕事，GPU2には別の仕事を」といった具合に，複数GPUを明示的に使い分けられるようになるわけだ。

　3つめのCross-process and Cross-API sharingは，Vulkan以外のKhronos製APIが管理する「メモリやリソースを相互共有する仕組み」にVulkanを対応させるものとなる。
　スマートフォンやタブレットといったモバイル系プラットフォームでは，VulkanとOpenGL ESを併用するようなアプリケーションがある。そんなアプリケーションでこの機能を活用すると，API間でデータをやりとりするときに無駄なバッファメモリコピーなどを行うことなく，相互に直接処理し合えるようになる。

　Advanced Compute Functionalityは，今どきのGPGPU（GPUコンピューティング）で使用頻度が上がっている16bitサイズのデータを，明示的に最適な方法で取り扱うための機能であるという。
　HLSL Supportは，DirectX系のプログラマブルシェーダ言語「HLSL」で書かれたシェーダプログラムを，透過的にVulkanでも利用できるようにする機能だ。詳細は後述するが，これには「SPIR-V」の機能向上が大きく寄与しているようである。
　最後にYCbCr Supportは，YCbCr型の色差映像データをネイティブに取り扱えるようにする拡張だ。これにより，YCbCrベースのビデオストリームとRGBベースのCGリソースとを，Vulkan内で透過的に取り扱えるようになる。

これからのOpenCLアプリはVulkanで動く!?

　前段で後述するとしたSPIR-Vは，Vulkan 1.1に合わせてVersion 1.3になった。
　SPIR-Vとは，Khronosが統括しているさまざまなオープンスタンダードAPI群が共通して利用する中間言語仕様のこと。誕生の経緯を含む詳細はSIGGRAPH 2017における筆者のレポート記事を参照してもらうとして，ここでは新バージョンの話を続けたい。

SPIR-Vを基盤としたAPI環境（Ecosystem）を示したスライドの最新版

　SPIR-Vのアップデートで注目したいのは，バージョン1.3の基盤を利用し，OpenCLベースのアプリケーションをVulkan上で動作させるフレームワーク「Clspv」がついにβ版まで到達したことだ。
　「GPGPU的な処理を行うOpenCLベースのアプリケーションを，なぜグラフィックスAPIであるVulkanで動作させるのか？」と疑問を持つ人がいるかもしれないが，実のところこのプロジェクトは，GoogleのAndroid戦略に関連した政治的な駆け引きとソフトウェアベンダー側の思惑とが交錯した結果としての折衷案として登場したものだったりする。

　もう少し具体的に説明しよう。GoogleはAndroid 7.0（Nougat）以降でVulkanを標準グラフィックスAPIとして採用し，プラットフォームに統合したが，一方でOpenCLの採用には消極的な姿勢を見せている。
　OpenCLは，対象ハードウェアを限定しない並列コンピューティング用プラットフォームであり，GPUだけでなく，CPUやDSPでも動作するものだ。しかし，OpenCLアプリケーションを相応の性能で動かせるGPUを備えたAndroid端末は，現状ではハイエンドの製品だけである。専用DSPを組み合わせるという手もあるが，最終的な端末の価格が上がることに変わりはない。
　Googleとしては，ハイエンド端末でしか実用的に使えないOpenCLを，現在のAndroid端末に持ち込むのは時期尚早と考えているようなのだ。

　ところが，そんなGoogleも，特定分野におけるOpenCLソフトウェア資産は，Android上で動かしたいと考えている。たとえば，Adobeが有する豊富なOpenCLベースの画像処理ライブラリなどだ。そういう経緯で，「OpenCLベースで構築された画像処理ライブラリを，VulkanのCompute Shaderベースで動作するコードへ変換するクロスコンパイラ」としてClspvの開発が始まったというわけである。

Clspvのベータ版がリリースされ，OpenCLアプリがVulkan上で動かせるように

　大人の事情で生まれたClspvであるが，Trevett氏によると，現在公開されているClspvのベータ版によって，20万行に及ぶAdobeの画像処理ライブラリをVulkanベースへと移植できたというから，その実力は相当なものだ。2017年にスタートしたClspvのプロジェクトは，着実な前進を示していると言えよう。

VRとAR，MRのためのオープンスタンダードAPI「OpenXR」，その開発進捗

　Oculus VRの「Rift」とHTCの「Vive」がデビューし，「VR元年」ともてはやされたのは2016年のこと。2017年にはMicrosoftのMixed Reality（複合現実，以下 MR）対応デバイスも登場したのも記憶に新しいところだ。
　現在もさまざまなVRやAR，MR対応ヘッドマウントディスプレイ（以下，HMD）が開発中なので，近未来的にはいままで以上に多くのVRやAR，MRプラットフォームが登場することになると思われるが，ここで問題となるのが「1つのアプリケーションを複数のプラットフォーム上で動作するようにするための移植プロセス」である。RiftとVive，「PlayStation VR」というVR HMDを例に挙げるまでもなく，HMDの基本的な機能要素が同じであったとしても，プラットフォームが異なれば，それを制御するソフトウェアの仕組みも異なってくる。

　大規模なソフトウェア開発スタジオであれば，個別のデバイスに合わせた最適化を行うことも可能だが，小規模なスタジオがそこまでするのはコスト的に難しい。そのため現状，小規模なスタジオは，「Unity」や「Unreal Engine 4」などといった，VRおよびAR対応のゲームエンジンを採用することになるわけだ。

既存のVRおよびARアプリケーションと開発環境，プラットフォーム，HMDの関係をまとめた模式図。これらを広くサポートするのは大変だ

　HMDメーカーのほうも大変である。他社より優れた機能や性能のHMDを開発したとしても、アプリケーションがなければユーザーに楽しんではもらえない。
　そこで現在，新興のHMDメーカーは，有力なVRやARプラットフォームとの互換機能を提供を提供したいと考えていたりするわけだが，対応プラットフォームごとにドライバを用意したり，用意できても今度はプラットフォームホルダー側との間で著作権やライセンス関連の問題が発生したりするため，互換機能を提供すること自体のハードルは決して低くない。
　そこで誕生することになったのが，Khronosの「OpenXR」である。

　下のスライドは，OpenXRのアーキテクチャをまとめた概念図だ。上がよりアプリケーションに近い層，下がよりハードウェアに近い層で，黄色いブロックが「OpenXRの担当する部分」となっている。

OpenXRのアーキテクチャ概念図

　上の概念図で黄色いブロックが2個あるのに気付いたと思うが，OpenXRは2段構成になっているのが大きな特徴だ。なぜ2段構成なのかと言うと理由は単純で，先ほど紹介した2つの負荷――1つは開発スタジオ側，もう1つはHMDメーカー側――をそれぞれ低減するためである。

　上側の黄色いブロックである「OpenXR Application Interface」は，ARやMR，VRアプリケーション開発者側の負荷を低減するもので，ARやMR，VRアプリケーション側がHMDを制御するために呼び出していたAPI「VR＆AR Vendor Runtime System」（以下，Vendorランタイム）の前に割って入ることになる。「HMDごとに用意されているAPIの仕様の違いを吸収する層」と言っていいかもしれない。

　一方，下側の黄色いブロックである「OpenXR Device Plugin Extension」はハードウェア開発者に向けたものだ。HMDのデバイスドライバは，HMDから得た生データをOpenXR Device Plugin Extensionに適合する形で渡すことになる。

　これら2つのOpenXR担当部分の間に立つのが，Vendorランタイムである。Vendorランタイムは，アプリケーションから来るデータとHMDから来るデータの双方を，共通規格であるOpenXR仕様で受け取れる。なので，これを入れ替えれば他社のHMDであるように振る舞う，つまり互換動作を実現しやすくなるという理屈だ。
　つまり，OpenXR Application Interfaceがカバーする範囲で開発したXRアプリケーションなら，Vendorランタイムを入れ替えるだけでさまざまなHMD上で動作するようになるのである。

OpenXRを利用して，1つのXRアプリケーションを複数のHMDで動作させたときの概念図。図の「Runtime A」は，OpenXR Device Plugin Extensionを使用しない場合の例である

コア機能とExtensionの扱いは，OpenGLの仕組みと同じ。Extensionが普及すれば，後のバージョンでコアに統合される

　OpenXRのワーキンググループが発足したのは2016年末のこと。それ以降，主要なゲームエンジンメーカーとVR HMDメーカー，GPUメーカー，スマートフォンメーカーが参加するようになり，今では大きなプロジェクトに発展してきているそうだ。とくに，「比較的閉じたイメージのHMDプラットフォームを推進しているSony Interactive EntertainmentやMicrosoftがこのプロジェクトに参加していることの意義は大きい」（Trevett氏）。

OpenXRに参加している企業。VR HMDメーカーはもちろん，GPUやゲームエンジン，VRプラットフォーム，スマートフォンメーカーなど，多くの主要プレイヤーが名を連ねている

　ここまでを踏まえたうえでTrevett氏は，OpenXRの代表的な機能のいくつかを紹介した。

　1つは，入力に関するAPIで，HMD用コントローラ側にあるどのボタンを押すとアプリケーション側ではどう反応するか」を割り当てられるという。
　たとえば，ジャンプというアプリケーション側のアクションを，A社のVR HMDでは右手側コントローラの［A］ボタン押下に，B社のフットペダル付きVR HMDでは左右のフットペダルを同時に踏む操作にそれぞれ割り当てるといったことが可能になる。

OpenXRでは，入力の割り当てを抽象化する仕組みを用意した

　映像表示も，同様の抽象化で各デバイスごとの独自性を吸収可能だ。たとえば，スマートフォン向けの1画面表示用ビューポートと，VR HMD向けに二眼表示を行う場合のビューポート，プレイヤーの周囲を囲む複数の壁面に映像を投影するビューポートをそれぞれ定義しておくと，アプリケーション側は最低限の変更で，さまざまな形態のXRディスプレイデバイスに対応できる。

表示デバイスを抽象化する仕組みを用意して，1つのアプリケーションがさまざまなデバイスに対応しやすくしている

　またOpenXRでは，アプリケーションのプログラム進行と映像の描画サブシステムを切り離して実装できるようになっている。特定のHMDやディスプレイデバイスの性能差がもたらす影響を最小限に抑える形でアプリケーション開発が行えるように工夫してあるというわけだ。
　ここでも例を挙げてみよう。たとえば，最大リフレッシュレートが60fpsのVR HMDと120fpsのVR HMDで，同じVRアプリケーションを動作させる場合，頭部の動きと表示する映像の時間的なズレの辻褄を合わせるために，いわゆる「タイムワープ処理」を行うことになるが，リフレッシュレートが異なるとタイプワープ処理のタイミングが変わってしまう。そんな場合でも，VR HMD側のドライバーがOpenXRに対応していれば，リフレッシュレートに応じたタイムワープ処理の最適化が不要になるのだ。

OpenXRでは，「描画開始」「描画終了」「次フレームの処理へ」といったタイミングをアプリケーション側で明示的に宣言することで，宣言を受け取ったHMD側が最適なタイムワープ処理を自動で行えるようになる。アプリケーション側はHMDの表示性能を知らなくてもいい

VR HMDでは，接眼レンズの歪みを逆補正した映像を表示している。そうした補正用のパラメータも，VR HMD側のOpenXR対応ドライバソフトが持っていれば，アプリケーション側が個別の映像補正処理を準備しなくていい

　ハードウェア開発者にもソフトウェア開発者にも朗報となりそうなOpenXRだが，残念なことにリリース時期は未定。ただ，Trevett氏は2018年内のリリースを見込んでいると語っていたので，Khronosの活動パターンから予想すると，2018年8月に行われるSIGGRAPH 2018のタイミングあたりで何らかの発表がある可能性は高そうだ。

採用を拡大するデータフォーマット「glTF」

データを大幅に圧縮する「Draco」も利用可能に

　セッションの最後にTrevett氏は，「OpenGL Transmission Format」こと「glTF」の近況についても説明した。
　glTFについての詳しい解説は，筆者によるSIGGRAPH 2017レポートを参照してほしいが，簡単に言えばglTFとは，クロスプラットフォームに対応した3Dグラフィックスアセットのフォーマットである。3Dグラフィックス関連のアセット（≒データ類）を自在に出し入れ（Transmit）できるフォーマットだから，「OpenGL Transmission Format」ということになる。

glTFとは，3Dグラフィックスアセットをインポート，またはエクスポートするためのクロスプラットフォーム対応フォーマットである。

　glTFの最新版である「glTF 2.0」はSIGGRAPH 2017のタイミングで正式リリースとなったが，Trevett氏が今回説明したのは，glTF 2.0リリース後の動向だ。
　現在，glTFは，非常に多くのツールやアプリケーションで採用が進んでいるそうで，有名どころではゲームエンジンの「Unreal Engine 4.19」や「Unity」，Adobeの画像合成ソフト「Adobe Dimension」などが対応しているという。
　変わったところでは，Facebookの対応が例に挙がっていた。試した人がいるかもしれないが，Facebookのエントリに3Dモデルをドラッグ＆ドロップすると，ライティングやシェーディングを施した3Dモデルをマウスでぐるぐる動かして見られるようになっているが，あの機能にglTF 2.0が使われているそうだ。

　glTF 2.0後という意味では，Googleの開発した3Dデータ圧縮技術「Draco」（関連リンク）を使うExtensionがglTFの拡張支援機能として2018年2月にリリースとなったこともトピックとして挙げられる。

　Dracoとは，3Dモデル（ポリゴンメッシュ）やポイントクラウド（法線や色，材質特性情報を持った点の集合体で，3D形状を表現するデータ形式）からなるデータを，オリジナル比で30〜40分の1近くまで圧縮できる技術である。Dracoの特許はGoogleが有しているが，オープンソースプロジェクトとなったため，Dracoを用いたファイルの圧縮や展開のコードは無償でソフトウェアへ組み込めるようになっている。
　Trevett氏はとくに“メモリ予算”の少ないスマートフォンや携帯端末での利用が期待されると語っていた。

3Dモデルのデータサイズを30〜40分の1近くまで小さくできるDracoのExtensionが2018年2月にリリースされた

DXRの登場で，OpenGLやVulkanはレイトレーシングに対応するのか？

セッション開催前に，筆者のインタビューに答えるTrevett氏。本稿は，インタビューの内容も反映したものになっている

　Trevett氏によるセッションの概要は以上のとおりであるが，グラフィックスに関わる重要なトピックの1つが抜けていることに気付いただろうか。そう，レイトレーシングだ。

　GTC 2018の前週に行われたGDC 2018でMicrosoftは，DirectXにレイトレーシングパイプラインを統合する「DirectX Raytracing」（以下，DXR）を発表した。これを受けて，Khronosが統括するOpenGLやVulkanに，同種の動きが起こるかどうかはとても気になるが，今回，レイトレーシング周りについてTrevett氏は何も語っていない。

　PowerVRを有するImagination Technologiesは，2011年にオープンソースのレイトレーシングAPI「OpenRL」を発表したことがあった。OpenRLをKhronosがオープンスタンダードとして採用するかについて筆者が質問したとき，当時のTrevett氏は，「レイトレーシングのオープンスタンダードAPIを策定するのは時期尚早である」という旨の回答をしていたが，あれから7年。MicrosoftとNVIDIAがタッグを組んで動き出した現在，もう「時期尚早」とは言っていられないはずである。

　果たしてKhronosは，レイトレーシングを巡って新しい動きを見せるのだろうか。DXRのリリースは2018年秋の予定なので，それまでにKhronos側からなんらかのアクションを見せるか否かは気になるところである。

Khronos Group 日本語公式Webサイト

Khronos Group 公式Webサイト（英語）