後藤弘茂のWeekly海外ニュース
GTCでKhronosが明らかにしたAPIアップデート
2017年5月9日 18:19
Nintendo Switchにも提供されるグラフィックスAPI「Vulkan」
NVIDIAが主催するGPUコンピューティングのカンファレンス「GTC(GPU Technology Conference) 2017」が、米サンノゼで開幕した。GTCは5月8日～5月11日(現地時間)にかけて開催され、初日の5月8日は、チュートリアル的なセッションが中心に行なわれた。GTCでは、コンピューティング系のセッションが中心だが、グラフィックス系のセッションもある程度含まれている。
今回のGTC 2017では、グラフィックスAPIの策定団体であるKhronos Groupが、API群の動向についての解説を行なった。Khronosは、2月のGDC(Game Developers Conference)時に、同グループのグラフィックスAPIである「Vulkan」が任天堂のゲーム機「Nintendo Switch」をサポートすることを明らかにしている。
Nintendo SwitchのグラフィックスAPIについては、NVIDIAが専用に開発した新API「NVN」が提供されている。NVIDIAはNVNだけでなく、ツールやライブラリなども提供している。また、KhronosグループのハイレベルAPI「OpenGL ES」も提供されていることが、明らかにされていた。
KhronosのグラフィックスAPIでは、OpenGL ESがハードウェアの抽象度が高く扱いやすいがハードウェアの性能を引き出しにくいハイレベルAPI。Vulkanが、ハードウェアの抽象度を引き下げ、プログラムしにくいが性能を引き出しやすいローレベルAPIとなっている。Vulkanのもともとの理念は、ゲーム機のグラフィックスAPIのようなローレベルAPIをクロスプラットフォームで提供することにあった。それがなぜ、ゲーム機であるNintendo Switchに提供されるのか。KhronosをとりまとめるNeil Trevett氏(Vice President Developer Ecosystem, NVIDIA/President, Khronos Group)は次のように説明する。
「Nintendo Switchでは、3つのAPIがサポートされている。NVIDIAが開発したNVNと、OpenGL ES、そしてVulkanだ。それぞれ、ハードウェアの抽象度が異なる。NVIDIAのAPIは、VulkanとOpenGL ESの中間にあたる。NVIDIA APIはVulkanに非常に近いが、Vulkanの方がさらにローレベルだ。開発者の異なるニーズに対応するためだ」。
通常のゲーム開発向けにはNVN、アプリケーション開発で容易にグラフィックス機能を使いたい場合はOpenGL ES、レジスタレベルでGPUを叩きたいというニーズに対してVulkanが提供されるという。ただし、ゲーム開発者によると、当初の開発キットではVulkanは提供されていなかったようだ。
バーチャルリアリティの標準API「OpenXR」
Vulkanについては、このほか、マルチGPUとVRのサポートが発表されている。ここでややこしいのは、Khronosが、バーチャルリアリティ(VR)のための、クロスプラットフォームAPI「OpenXR」も発表していることだ。
「VulkanでのVRサポートと、OpenXRは、カバーする領域が異なる。VRに対応するレンダリングAPIはVulkanだ。しかし、レンダリング以外はどうか、という疑問があった。それに応えたのがOpenXRだ。OpenXRがVRの全てをカバーして、Vulkanを置き換えるわけではない」とTrevett氏は説明する。
センサートラッキングやデバイスディスカバリー、デバイスイベントなど、レンダリング以外のVR回りの全てをカバーするAPIがOpenXRとなる。通常のヘッドモーショントラッキングだけでなく、アイトラッキングやハンドトラッキングなどもカバー。それらのセンサデータを、高精度に扱いながら、抽象化する。
「異なるタイプのトラッカーが、OpenXRによって互換で扱うことできるようにしたい。非常にフレキシブルで拡張性に富んだAPIにするつもりだ。将来的には、思考トラッキングもサポートできる拡張性を持たせたい(笑)」(Trevett氏)という。
OpenXRの狙いは、現状のVR市場の打破にある。現在は、VRアプリケーションを、それぞれVRデバイスに向けて開発しなければならない。市場はデバイス毎に分断されており、ポータビリティが低い。OpenXRの目的では、VRアプリケーションを書いたら、それがどのVRデバイスでも走るようにすることにある。その場合、デバイス毎に異なるトラッキング技術を抽象化することが必須となる。
この目標のために、OpenXRはデバイスごとに2層のAPI構造となっている。各ベンダーのプラットフォームランタイムに、アプリケーションがアクセスするためのアプリケーションインターフェイス。そして、各ベンダーのランタイムがデバイスにアクセスするためのドライバレイヤ。アプリケーション側からは共通APIで、異なるVRシステムのランタイムにアクセスできるようにする。一方、ベンダーごとのライタイムに、ドライバでデバイスを組み込むことも可能にする。
OpenXRにはOculus、Steam VR、OSVR、Gear VR、DaydreamといったVRベンダーがサポートを表明している。これが可能になっているのは、OpenXRが、それぞれのベンダーの固有のAPIと併存できるからだ。各VRベンダーは、自社のVRランタイムを拡張して、自社専用APIだけでなく、OpenXRもサポートできるようにすることができる。自社APIのアプリケーションはそのまま継続しながら、OpenXRによる移植アプリケーションを増やすことができる。
また、OpenXRでは、OpenGLと同様にベンダー固有のエクステンションを許容する。例えば、ベンダーがドライバレイヤで拡張することで、新技術の導入を容易にする。こうした許容方針によって、OpenXRを自然にVRのクロスプラットフォームスタンダードへと持って行こうとしている。
現在、KhronosのAPI策定は12から18カ月かかっている。OpenXRの場合は、昨年(2016年)の12月に公開され、GDCで名称と方針が発表された。順当に行けば、2018年のGDC時までに策定されるかもしれないという。
ニューラルネットワークへの対応を急ぐKhronos
Khronosは、並列コンピューティング向け言語では「OpenCL」を策定している。今回のGTCでは、コンピューティングのOpenCLとグラフィックスのVulkanのコンバージェンスを目指す「OpenCL-V」ロードマップが明らかにされた。薄いVulkanのランタイムを拡張して、OpenCLをその上に載せようという方向だ。また、深層学習への対応のために、OpenCLで低精度の演算をサポートすることも明らかにされている。
深層学習では、KhronosはコンピュータビジョンのクロスプラットフォームAPI「OpenVX」も急発展させている。OpenVXは、NVIDIAが力を入れているGTCの本題である深層学習に深く関わる。OpenVXについては、また別な機会にレポートするが、OpenVXに絡んだ動きとして、Khronosが「NNEF」というフォーマットを明らかにしたことが面白い。
NNEFはニューラルネットワークモデルの交換フォーマット規格だ。異なるデバイス間で、ニューラルネットワークファイルを交換できるようにする。
「NNEFはAPIではなく、データ交換フォーマットだ。現在は、それぞれプロプラエタリな方式になっているニューラルネットワークのデータを移行できるようにする。例えば、トレーニングしたニューラルネットワークを、低消費電力の推論デバイスに容易に持って行けるようにする」とTrevett氏は説明する。
深層学習では、IoT(The Internet of Things)側のエッジデバイスで、推論(インファレンス)のサポートへの期待が高まっている。Khronosの狙いは、そうしたデバイスでの標準を抑えることにある。
