OpenGL 4.6の進化点やOpenCLの将来について，Khronos Group代表のNeil Trevett氏に聞いてみた

Neil Trevett氏（President，Khronos，Vice President Mobile Ecosystem，NVIDIA）

　筆者のSIGGRAPH取材では，OpenGLやVulkanといったAPIの標準化を担当している業界団体Khronos Group（以下 Khronos）の代表を務めるNeil Trevett（ニール・トレヴェット）氏にインタビューするのが，毎年恒例となっている。
　SIGGRAPH 2017でも，Trevett氏にインタビューを行い，2017年までの取り組みと，今後Khronosが重点を置く分野について，さまざまな話を聞くことができた。代表が語るKhronosの重点分野について，簡単にまとめてみよう。

OpenGL 4.6がリリース

Vulkanとの相互連携機能を搭載

OpenGLは，2017年で誕生から25年めを迎えた。Khronosのスライドにも，25周年を祝うコミカルなイラストが掲げられていた

　2017年におけるKhronosのホットトピックと言えば，最新版のOpenGLである「OpenGL 4.6」のリリースがSIGGRAPH 2017会期中に行われたことだ。
　ただ，先に言ってしまうと，新シェーダのサポートのように大きな拡張を含むものではなく，「OpenGL 4.5」から0.1増えただけに相応しいマイナーチェンジである。とはいえ，注目すべきポイントは3つほどあるので，1つずつ紹介していこう。

　1つめは，OpenGLのコアシステムに対する「SPIR-V」の統合が，さらに進んだという点だ。SPIR-Vとは，Khronosが統括しているさまざまなオープンスタンダードAPI群において，共通して利用できるように推進している中間言語仕様のこと（関連記事）。

　そもそもSPIR-Vの原型である「SPIR」（Standard Portable Intermediate Representation）は，OpenGLではなく，並列コンピューティング向けAPIである「OpenCL」の中間言語仕様として採用されたものである。そのSPIRもまた，「LLVM」（Low Level Virtual Machine）という別の中間言語仕様をもとに作られたものだった（関連記事）。

　SPIRは，「OpenCL 1.2」で「SPIR 1.2」，「OpenCL 2.0」では「SPIR 2.0」という関係具合にアップデートを続けていたのだが，2015年リリースの「OpenCL 2.1」やグラフィックスAPIの「Vulkan」からは，Khronos独自開発のSPIR-Vに移行している。
　余談だが，この方針転換は，LLVMの標準化団体であるLLVM Developer Groupとの政治的な問題を回避しながら，Khronos内で自由に仕様を決められるようにするためだと言われていた。いずれにしても，2015年を境に，Khronosは独自開発のSPIR-Vを，OpenCLやOpenGL，Vulkanといった，Khronos策定のAPIに統合する方向で進んでいたわけだ。

　話を戻すと，OpenGL 4.6ではSPIR-Vの完成度が高まったことで，「シェーダプログラミング環境の汎用性がより向上した」と，Trevett氏は話す。
　Khronosが新たに公開したシェーダフロントエンドコンパイラの「Glslang」は，OpenGL系のシェーダプログラミング言語「GLSL」と，DirectX系のシェーダプログラミング言語「HLSL」の両方に対応しており，これらのソースコードからSPIR-Vの中間言語コードを出力できるという。
　SPIR-Vで出力した中間言語コードは，新ツールとしてKhronosが提供するソースコードジェネレータ「SPIR-V Cross」を用いることで，GLSLやHLSLはもちろん，AppleのiOSおよびmacOSで使うシェーダプログラミング言語「MSL」（Metal Shading Language）への逆コンパイルにも対応するというのが面白い。
　SPIR-Vを基盤とする開発環境が進化したことで，OpenGL 4.6では，シェーダプログラムがほかのAPIに対して，より移植しやすくなったとも言えるだろう。

SPIR-Vを基盤としたAPI環境を示したスライド。SPIR-Vがさまざまな言語や開発環境とAPIを結んでいる

　OpenGL 4.6における2つめのポイントは，OpenGLとVulkanの相互連携を拡張する機能の実装だ。
　相互連携と聞いて，「そもそも，OpenGLのオーバーヘッド問題を低減するのがVulkanでしょう？　オーバーヘッドの大きいOpenGLを，Vulkanと相互連携させることにどんな意味があるの？」と感じた人もいるだろう。確かに，ゲーム開発おいてはそのとおりで，あまり意味はない。
　しかしVulkanは，アプリケーションからGPUを操作することに特化した設計になっているために，一般的なアプリケーションを作る開発者にとっては，難度が高いのだ。グラフィックスエンジン開発やゲームエンジン開発を担当する開発者でもないと，Vulkanをフル活用するのは難しい。Trevett氏も，GDC 2015における筆者のインタビューに対して，「Vulkanのローレベル制御がすべてのプログラムに適しているとは考えていない。ドライバに負担をかける作業が必要なソフトも少なからず存在している」と説明していた（関連記事）。

　一方，OpenGLは，オーバーヘッドが大きいとはいえ，基本的なグラフィックスプログラミングにおける難度は，Vulkanと比べれば低い。また，25年にもなる歴史があるため，膨大なソフトウェア資産がある。それゆえに，Vulkanリリース後も，新版のOpenGLがリリースされているわけだ。とくに，CADソフトや業務用のグラフィックスソフトなどは，長年OpenGLベースでバージョンアップを重ねてきたものが多く，全面的にVulkanへと移行する必要性があまりない。
　しかし，そうしたアプリケーションでも，非常に負荷の高い部分やリアルタイム応答性を高めたい部分には，Vulkanを利用して高速化したいというニーズがあるのだと，Trevett氏は説明する。そうした要望を受けて実装されたのが，OpenGLとVulkanの相互連携拡張というわけだ。
　具体的な要素としては，OpenGLでの実行結果とVulkanでの実行結果それぞれを相互に交換しあえるようなバッファの共有機能がメインになるようだ。

OpenGLとVulkanの相互連携機能が，OpenGL 4.6へ搭載された

　最後の3つめは，細かな機能のアップデートだ。Trevett氏が，例として挙げたのは，

• シェーダのコンパイルスレッドを複数発行できるように
• OpenGLのソフトウェアレンダリングで，テクスチャの異方性フィルタリング（Anisotropic Texture Filtering）を標準仕様として採用した

といったものだ。
　「異方性フィルタリングを今さら標準サポート？」と思った人もいるだろうが，意外なことに事実である。テクスチャの異方性フィルタリング（関連記事）は，PCゲーマーならグラフィックス設定の項目として，馴染みのあるキーワードだと思うが，従来は，Evans ＆ Sutherland（E＆S）という米国企業が特許を有する技術だったのだ。
　E＆Sは，3Dグラフィックスに関する基本特許を幅広く押さえている企業で，NVIDIAもE＆Sから，そうした特許のいくつかを買い取ったことがあるほどだ（関連リンク）。2016年に，E＆Sが有する異方性フィルタリングの特許が切れたそうで，ついにソフトウェアレンダリングにおいて，この機能を実装することが可能になったというわけである。

OpenGL 4.6のアップデート要素を列挙したスライド

　最後に，対応ドライバソフトのリリースだが，NVIDIAが今回も一番乗りを果たしており，SIGGRAPH 2017の会期中に，OpenGL 4.6対応のGeForceおよびQuadro用ドライバとなるバージョン382.96をリリース済みだ（関連リンク）。ただし，あくまでもβサポートとのこと。
　なお，本稿執筆時点での公式最新版グラフィックスドライバとなる「GeForce 385.41 Driver」は，OpenGL 4.5までしか対応していない。OpenGL 4.6の仕様を試したいのなら，上記関連リンクにあるドライバソフトを使う必要がある。

2017年はVulkanのアップデートなし

移植工程を短縮するラッパーの開発が進む

　続いての話題はVulkanだ。
　ご承知のとおり，Vulkanは，既存のAPIよりもハードウェアに近い層で，GPUをほぼ直接駆動できるグラフィックスAPIとして，2016年に正式リリースされたグラフィックスAPIである。
　Trevett氏は，ゲーム関連情報サイト「Game Debate」が実施した「Vulkan vs DirectX 12, Which is the Better Graphics API?」（DirectXとVulkan。どっちが優れたグラフィックスAPIか？，関連リンク）というアンケートで，VulkanがDirectXの16倍もの得票で圧勝したことを嬉しそうに説明していた。登場後，わずか1年でこれだけの評価を受けたことには，Khronosも大満足といったところか。

　投票結果に納得する日本のゲーム開発者がどのくらいいるのかはともかく，少なくともゲームエンジンやグラフィックスミドルウェアにおいて，Vulkanの採用が順調に増えてきているのは事実である。
　2大ゲームエンジンである「Unreal Engine 4」と「Unity 5」は，2016年のうちにVulkan対応を済ませているし，Crytekも，2017年7月にプレビューリリースした「CRYENGINE 5.4」でVulkanに対応といった具合だ。

Vulkanに対するゲームエンジンへの対応状況を示したスライド。大手ゲームエンジンのほぼすべてが対応を終えたという

　またVulkanは，Android OSや任天堂のNintendo Switchなど，メジャーなプラットフォームにおける標準グラフィックスAPIとしての採用も進んでいるとのこと。ゲーム業界における地位は向上し続けている。

Vulkanに対応するハードウェアおよびソフトウェア企業とプラットフォームを示したスライド。AndroidやNintendo Switchも対応済みだ

　まだVulkan1.0がリリースされて1年が経過したばかりということもあって，
2017年は，Vulkanに新機能を導入するようなアップデートの予定はないそうだ。
　その一方で，Khronosは，Vulkanを取り巻く環境の改善に取り組むプロジェクトを発足させたという。具体的には，VulkanとほかのAPI間で，グラフィックスアプリケーションを移植しやすくすることを目指すプロジェクトなのだと，Trevett氏は説明する。

　現在，ゲームを含むグラフィックスアプリケーションは，動作対象となるプラットフォームごとに，グラフィックスAPIを使い分けて開発するのが基本である。たとえば，iOS用アプリはMetal，Android用アプリならVulkan，WindowsやXbox用アプリはDirectXを使って開発するといった具合だ。この場合，あるアプリを複数のプラットフォームに展開するには，グラフィックスプログラム部分は，それぞれのAPI仕様に合わせて移植作業を行わなければならない。
　この面倒な工程にかかる手間をなんとか減らすする試みとして，「Vulkan Universally Portable Subset」（仮称，以下 VUPS）と呼ばれるラッパー的な仕組みを開発するプロジェクトが発足したという。

左が従来の移植，右がKhronosが提唱するVUPSを利用した移植をイメージしたスライド

　Vulkan，DirectX 12，Metalは，生まれや育ちは違うものの，いずれもハードウェアに近い層でGPUを駆動するAPIであり，機能的に似た部分は多い。Trevett氏によれば「85％くらいが方言的な違いに留まる」とのことで，機能的には大差がないそうだ。
　たとえば，Vulkanならば「vk」，DirectX12ならば「d3d12」を接頭語とした似たような名前のAPIがたくさんある。座標軸の取り扱い方やパラメータの指定法といった違いもあるが，用意されているAPIのラインナップは，かなり似通っているという。

　そこで，共通している部分はVUPSのトランスレータ（Khronosでの呼称。実質的にはコンバータ的なもの）が差異を吸収し，どうしても吸収しきれない部分は，VUPS用に用意するVulkanの拡張APIを使って吸収する手法を導入しようとしていると，Trevett氏は説明していた。
　また，シェーダ言語については，OpenGL 4.6で触れたSPIR-Vを使うことで，対応できると考えているということだった。

VUPSの概念を示したスライド

OpenCLソフトウェア資産をVulkanで動作させるソリューションを開発

　次の話題は，並列コンピューティング向けのAPIであるOpenCLの将来についてだ。

OpenCLは，NVIDIA製GPUでも，AMD製GPUでも，あるいはCPUでも動作する並列コンピューティングのプラットフォームである

　Khronosは，OpenCLの最新版である「OpenCL 2.2」を2017年5月にリリースした。OpenCL 2.2は，2015年に登場した「OpenCL 2.1」のマイナーチェンジ版であり，基本的な機能面で大きく変わったところはない。ただ，OpenCL 2.1から始まったC＋＋言語への対応がさらに進み，OpenCL 2.1で利用していた「C＋＋11」よりも新しい「C＋＋14」に対応した。
　また，OpenGL 4.6の話でも触れたが，OpenCL 2.1と同様に，SPIR-Vベースで構築されているところは変わらない。

OpenCLの歴史

　Trevett氏は，OpenCL 2.2以降のロードマップについて，3つのポイントで解説した。
　1つめは，C＋＋の次期バージョンである「C＋＋17」への対応だ。
　Microsoftの並列コンピューティング向け技術である「C＋＋ AMP」や，NVIDIAの「CUDA」もC＋＋17への対応を進めていく見通しだそうで，開発者の負担を減らすためにも「並列コンピューティングに向けた拡張型C＋＋言語の仕様を，業界でちゃんと策定したほうがいいのではないか」という気運が高まってきたと，Trevett氏は説明する。
　そこで今後は，C＋＋言語の標準仕様策定を担当する標準化団体であるISO（国際標準化機構）やIEC（国際電気標準会議）などと連携して，仕様を決めていく方針を固めているのだとか。
　機械学習型の人工知能やコンピュータビジョン処理，そして，それらをベースにして応用した自動運転技術など，並列コンピューティングに対する関心は高まっており，今後，ソフトウェア資産の利用しやすさを考えると，プログラミング言語の違いに起因するフォーマット競争は，このあたりで休戦すべき，という判断なのかもしれない。

　2つめは，コンピュータビジョン向けDSP（Digital Signal Processor）や映像信号プロセッサ（Image Signal Processor，ISP），機械学習アクセラレータ（Tensor Processing Unit，TPU）などに向けたOpenCLのサブセット版を開発するプロジェクトの発足だ。
　現在のOpenCLに対応する各種プロセッサは，最低でも単精度浮動小数点数（FP32）に対応していなければならなかった。しかし，機械学習型の人工知能やコンピュータビジョン処理，および，それらを応用した自動運転技術などに使うDSPやISPには，整数（Int）や半精度浮動小数点数（FP16）でも精度は十分だったりする。
　組み込み機器の世界では，余計な機能をそぎ落としたプロセッサを開発するのはよくあること。そのため，FP32を省いたプロセッサでも，OpenCLに対応したいという声が，業界から上がってきているという。Trevett氏によると，こうした要望に応えるべく，OpenCLの組み込み機器向けサブセットを用意してはどうか，と検討が始まったそうだ。

　名前はまったく決まっておらず，仮称として「OpenCL for DSP」と呼ばれているそうだ。イメージ的には，OpenGLに対するOpenGL ESの近い関係なので，筆者は「OpenCL ES」あたりに落ち着くような気がしている。

OpenCLとVulkanのロードマップを示したスライド。下にOpenCL for DSPがある

　3つめは，OpenCLをVulkan環境で動作させようというプロジェクトだ。
　特殊なジオメトリ処理や，プログラマブルシェーダでは行いにくいポストエフェクト処理といった一風変わったグラフィックス処理をGPGPU的な手法で処理しようとした場合，VulkanにあるCompute Shaderを使えば大抵は十分なはずだ。それにも関わらず，OpenCLをVulkan環境で動かすことには，大きな理由があると，Trevett氏は述べる。

　その切っ掛けは，GoogleがAndroidプラットフォームでのOpenCL対応を拒んでいることにあるようだ。Googleは，Android 7.0以降の標準グラフィックスAPIとしてVulkanをプラットフォームに統合した（関連記事，端末が対応するかどうかは，端末メーカー次第）。これは，Vulkanがグラフィックス専用APIだからだという。
　一方，OpenCLは，並列コンピューティングのためのプラットフォームであり，対象とするプラットフォームは限定していない幅広いものだ。しかし，Googleとしては，AndroidデバイスでOpenCLを実行することに興味がないのか，OS側でOpenCLをサポートする動きを見せたことはない。

　Trevett氏が言うには，そんなGoogleであっても，「特定分野のOpenCLソフトウェア資産は，Androidプラットフォームで動かしたいと強く思い始めている」のだとか。
　たとえばGoogleは，Adobe Systems（以下，Adobe）がOpenCLベースで構築した豊富な画像処理ライブラリをAndroidで動かしたいと考えているという。また，競合のAppleが2017年6月に発表したiOSやmacOS向けのAPI「Metal 2」は，データ並列コンピューティング処理に特化した機能を備えていることもあって，Googleも呑気に構えていられなくなった，ということだそうだ。

コンピュータビジョン処理はOpenVX対応の専用プロセッサに担当させるのがセオリー。しかし，スマートフォン向けGPUでも，GPGPU処理に対応しているものが増えているので，OpenCLのソフトウェア資産が動作するVulkan環境で実装させるというのもありえる

　Trevett氏によるとGoogleは，「OpenCLは嫌だけど，Vulkan環境でOpenCLソフトウェア資産を動かすというアプローチなら，ギリギリOKとする」方針に変更したそうで，それを受けて今回のプロジェクトがスタートしたという。
　現状では，VulkanとOpenCLのそれぞれを大きく変えたり拡張したりするアプローチではなく，OpenCLのソフトウェア資産をVulkan環境下で動作するコードに変換するクロスコンパイラ「Clspv」（仮称）を開発する方針になっているそうだ。

開発するクロスコンパイラは，仮称として「Clspv」という名前が付いている。OpenCLの「Cl」と，SPIR-Vの略である「spv」を合わせた造語だろう

　このプロジェクトには，GoogleとAdobeのほかに，クロスコンパイラ開発で知られるイギリスのCodeplayが参加しているとのこと。リリース時期などはまったく未定であるそうだ。

glTFは物理ベースレンダリングに対応

WebGLはFlash終了問題が普及の追い風に

　近年，Khronosが力を入れている新しい取り組みに，「OpenGL Transmission Format」，略して「glTF」と呼ばれるクロスプラットフォームに対応した3Dグラフィックスアセット（データセット）のフォーマット，Trevett氏が言うところの「トランスミッション」規格がある。
　ここで言うトランスミッションというのは，大雑把に言うとインポートとエクスポートのことだ。

glTFとは，3Dグラフィックスに関連したアセットを，自在にインポートまたはエクスポートするための規格だ

　glTFは，3Dモデルデータだけでなく，動き（アニメーション）も含めた3Dグラフィックスのシーンをまるごと扱えるファイルフォーマットである。具体的には，シェーダーやテクスチャ，アニメーション（キーフレーム），スキニング情報などのデータを含めることが可能だ。
　WebGLを用いれば，Webブラウザでも3Dグラフィックスを動かせる時代となったことを踏まえて，そうした環境でも利用しやすいように，3Dモデルやテクスチャ，モーション，シェーダーといったシーンを構成するデータをワンパッケージに収められる標準的なファイルフォーマットが欲しい，という要望を受けて誕生したのがglTFである。
　最初の正式バージョンである「glTF 1.0」は2015年にリリースされ，2017年6月には「glTF 2.0」が登場した。glTF 2.0で重要なポイントは，物理ベースレンダリング（以下，PBR）に対応できるようになったことだ。

glTF 2.0が扱えるデータの種類

　Unity 5やUnreal Engine 4といったメジャーなゲームエンジンは，すべてPBRに対応しており，スマートフォンへの対応も済んでいる。スマートフォン向けゲームで，PBRがごく当たり前のものとして利用される日も近いだろうということで，glTFも対応したというわけだ。
　PBRは，ゲームエンジンやレンダラーごとに，材質を記述するパラメータの種類が異なるが，このあたりは最小公倍数的に，現在使われているものを一通り対応できるようにフォーマットを設計したそうである。

glTF 2.0で取り扱われるPBRのパラメータ

WebGL対応ブラウザ上で3Dモデルを閲覧できるサービス「Sketchfab」も，早々にglTF 2.0へ対応。こちらのサンプルページではPBRベースのヘルメットをグリグリと回しながら眺めることができる

Windows 10のCreators Updateでプリインストールアプリとなった「View 3D」もglTF 2.0対応だ

　リリースされたばかりのglTF 2.0だが，IT業界における採用ペースは，とても速いそうだ。たとえば，DCCツールの「Blender」が対応しているほか，Windows 10 Creators Updateのプリインストールアプリである「Paint 3D」「View 3D」も対応アプリに名を連ねている。

　Trevett氏によれば，Microsoftは次なる大きな一手として，OfficeシリーズのglTF対応を計画中だとのこと。近い将来には，3Dグラフィックスパートをゲームエンジンで制作し，そのデータをPowerPointのプレゼンテーションに組み込むといったことも可能になるかもしれない。

業界のglTF 2.0対応は急速に進んでいることを示すスライド

　さらにTrevett氏は，glTFの盛り上がりと連動する形で，「WebGL」に対するIT業界の関心が高まっていると，指摘する。
　WebGLは，3DグラフィックスをWebブラウザから取り扱えるようにする仕組みで実質的に「OpenGL ESのWeb版」といったものだ。初代のWebGL 1.0は，OpenGL ES 2.0相当の機能を備えて2011年に登場。2017年1月にリリースされた最新版のWebGL 2.0になると，OpenGL ES 3.0相当の機能を備えている。DirectXの世代に当てはめると，OpenGL ES 3.0はDirectX 10世代相当になるので，WebブラウザでPlayStation 3以上，Wii Uと同等のグラフィックス表現ができるようになったと言えよう。

　なぜglTFとともにWebGL 2.0が，業界の関心を集めているかといえば，Flashの終焉が近づいているためでもある。
　Adobeは，2020年末にFlashの配布と更新を停止すると発表した。それにより，今後，インタラクティブかつリッチなグラフィックスを活用したWebコンテンツを実現するには，HTML5とWebGLの組み合わせが主流となることに拍車がかかるといわれており，Webアプリ開発シーンにおいても3Dグラフィックスを取り扱う機会は増加していくだろう。だからこそ，glTFが重要度を増しているのだ。

Flashの終焉（EOL，End of Life）によって，WebGLの活用が広がると見られている

　このような経緯もあり，glTFは，ゲーム開発や映像制作などでの活用はもちろんのこと，スマートフォンや組み込み機器での利用も想定して，仕様を策定していると，Trevett氏は説明していた。

　PCやスマートフォンと比べてスペックの低い組み込み機器での利用を想定するとなれば，重要となるのはデータサイズだ。その場合，データの圧縮が重要度を増してくる。
　そこでKhronosでは，Googleが開発した3Dモデル（ポリゴンメッシュ）やポイントクラウド（法線や色，材質特性情報を持った点の集合体で3D形状を表現するデータ形式）を30〜40分の1近くまで圧縮できる3Dデータ圧縮技術「Draco」（関連リンク）を組み込む計画を進めているとのこと。Trevett氏によれば，これにはGoogleも乗り気だという。
　もちろんDracoの特許はGoogleにある。ただ，Khronosが展開するglTF 2.0に組み込まれれば，ソフトウェア開発者は，無償でDracoを用いたファイルの圧縮や展開のコードを，ソフトウェアに組み込めるようになるわけだ。

Googleの3Dモデル圧縮技術DracoがglTFへ採用の見込み。ただ，導入時期は未定とのこと

AMDの「プリミティブシェーダ」は，OpenGLやVulkanに取り入れられるのか？

　せっかく，Khronosグループの代表に話を聞ける機会なので，AMDがVega世代GPUに搭載した「プリミティブシェーダ」の取り扱いをどう考えているのかも聞いてみた。

　プリミティブシェーダとは，煩雑な作りになってしまった現在のジオメトリパイプラインを整理整頓したシェーダアーキテクチャで，AMDが，Radeon RX Vegaシリーズに搭載したものだ（関連記事）。ただ，その機能を使う手段をAMDは公開しておらず，いまだに「謎の新機能」のままでもある。

　Trevett氏によると，「今のところAMDから，プリミティブシェーダに関する正式な提案は受けていない」とのこと。そのため，「直近で，OpenGLやValkunに組み込まれる予定はない」と明言していた。GPUメーカーが新搭載した独自機能は，OpenGLのコア機能ではなく，拡張仕様（Extension）として導入するのが常だが，そちらからの公開もないようだ。
　しかし，KhronosのメンバーにはAMDの社員も多くいるので，いずれ何らかのアクションがとられるのではないかということで，「何か進展があれば，来年のGDC 2018で報告ができるだろう」と，Trevett氏は話していた。

　プリミティブシェーダについては，AMDの競合であるNVIDIAの動向も気になるし，OpenGL/Vulkanの競合である，MicrosoftのDirectXがどう対応するのか（あるいはしないのか）も気になるところ。新しい情報が出てくることを期待したい。

Khronos Group 日本語公式Webサイト

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