各社GPU SDK比較2015

Ancient 3D tablet

追記: GoogleはSwiftshaderをオープンソース(Apache license)にした https://swiftshader.googlesource.com/SwiftShader/
追記: Transgamingには結局Gametree以外の事業が残らなかった。このためSwiftshader(の外販)も無くなった。
追記: IntelはINDEをやめて個々のツールを個別または有償のSystem Studioのバンドル提供に切り替えた。これによりGPAは無償に戻った。OpenCL SDKはサポートアカウントのセットアップを促されるが、実際にはダウンロード登録時のe-mailにダウンロードリンクが来るので、そちらからDLする。
追記: MSは自社のVisualStudio用GDBプラグインのソースコードを公開した : http://blogs.msdn.com/b/vcblog/archive/2015/07/20/source-now-available-for-gdb-lldb-debug-engine.aspx

前回からだいたい2年経ったのでアップデートの時期。

2013 → 2015

ここ2年の変化として大きいのは:

  • 意外と変化が無かった。これは不味い兆候で、特にコンピュートシェーダ(GLES3.1)やOpenCLのようなGPGPUへの進出は進んでいない印象がある。GPUIPベンダはAPIの移植性よりもソリューションパッケージの提供を選択しつつある。例えば、Khronosのコンピュータビジョン向けAPIであるOpenVXは今のところNVIDIAとVivanteしかconformant productを出していない。
  • Metalのデスクトップへの適用等モバイルファーストの進行。Appleは自社の(現状PowerVR向け)専用API/シェーダ言語であるMetalをデスクトップにも展開することを発表した。MetalはClang/LLVM上に実現され、事前コンパイルされるシェーダ言語を備えており、ソースコードを動的にビルドするスタイルのAPIから脱却しつつある。Next OpenGLと謳われるVulkanもSPIR中間表現によって事前コンパイルを実現するので、これは大きな傾向になりつつある。
  • リッチゲーミングの復権。特に日本でゲーム開発費が高騰している。PS4やXboxOneのロンチは成功裏に終り、少くとも今後2年程度に亘ってゲーム表現の基準となると考えられる。それまではDX9レベル、すなわちOpenGL ES2レベルのGPUが基準線であったのに比べるとレベルは大きく飛躍しており、OpenGL ES3.xとはよく対応しない。表現手法の差を吸収するためのゲームエンジンに求められる努力は年々大きくなってきており、モバイルにおけるUnity一強に繋がっていると考えている。
  • MS / Intelの巻き返し。MSはVisualStudio2015でAndroid / iOS開発をサポートするなど、かなりアグレッシブにクロスプラットフォーム化を進めている。また、凄まじい値付けによりタブレット市場でのWintelの存在感を維持している。

おそらく、GPU多様性は現状がピークで、今後は環境毎の収斂が進むのではないだろうか(例えばWindows上のPowerVRは今後採用されるかというと難しいポイントになりつつある)。言い換えれば、今が一番GPU SDKが面白い時期だと思う。Vulkanが来るあたりが盛り上りの最高潮だろう。

"その他"組の動向

KhronosのOpenGL ES Conformant productsページは非常にウォッチしがいがある。例えば、SonyがVita/PS4やWindows向けにOpenGL ESを開発していたり(今は亡きPlayStation Mobileが採用していた)、ソシオネクストが地味にUniphierの新版を提出している等。
Uniphier(PH1-Pro5)は普通のARM SoCになっている( http://www.socionext.com/jp/products/imaging/smarttv/ )。開発当初は独自RISCだった気がするが。。ソシオネクストは富士通/PanasonicのシステムLSI事業をスピンアウトしたもの。富士通成分が高い( http://pc.watch.impress.co.jp/docs/column/semicon/20150316_692816.html )が、UniphierのようなSoCも継続しているようだ。特に他所のGPU IPをライセンスしたという話は聞かないので、独自GPUなのはそのままなのではないかと思われる。
簡単に言って"その他"組に良いニュースは無い。また、いづれのベンダもSDKを公開していないのも前回同様。

PICA200がNintendo 3DSに採用されたことで知られるDMPは、SMAPH-HでOpenGL ES3.0サポートを果たした。これは日系のGPUベンダではUniPhierのような内製のものを含めてもたぶん初で、珍しい。
公開されているIRでは2016年から展開予定の新IP(ビジョン物)についてかなり強気な展開を予測しているのが目を引く。2年前は存在したOpenGL ESトレーニング事業はページごと無くなっており、撤退したものと思われる。
2年の間には新規のDesign Winもあり、グラフィックスIP事業が依然同社の軸であることは窺わせる。

PC-FXGAの血を引くTAKUMIは特に動向を開示していないがここ2年ほど"適合試験実施予定"となっていたGS3000系コアの適合試験が2015年になって実施されているのがKhronosのページから確認できる。何か有ったのだろうか。。(ただし本家サイトは更新されていない)(このページだとまだ実施予定になっている - http://www.gshark.com/products/index.html )
ETには毎年出展しており、運営実態が無いというわけではないようだ。新規グラフィックスIPは2012年のGS3000以降アップデートが無い。

Broadcomは何といっても自社のGPUドライバをオープンソースにした( http://d.hatena.ne.jp/mjt/20140303/p1 )のが注目される。ただ、それ以降はこれといった活動は見られない。(追記: そういえばAmazon Fire TV stickがVideoCoreだった。。)
raspberry pi 2ではARM版Windowsも動作するので、ついにDirectXで駆動されるVideoCoreが拝めるかもしれない。

Transgamingは既に歴史と伝統ある高速ソフトウェアレンダラSwiftShaderを未だに外販しているとともに、GoogleのOpenGL ES実装であるANGLEの重要なコントリビュータでもある。
ただ、NVIDIAにグラフィックス以外のクロスプラットフォーム技術(TransgamingはWineをカスタマイズしたCiderソリューションでも知られていた)を売却した( https://www.transgaming.com/news/nvidia-acquire-transgaming-s-cross-platform-portability-technology )。おそらく、NVIDIAはクラウドゲーミング(Grid)のためにエミュレータを活用するのだろう。

Intel

Intelは分散していた開発ツールをIntel INDEに統合し、他のベンダが無料で提供しているツール(フレームアナライザ等)を有償で提供している。Professional Editionが無料なのは8月末まで！(追記: 結局無償期間が2016/1Eに延長された後INDEバンドルそのものが廃止されてしまった)。Intel Compilerはまだ有償のまま。また、残念ながらVTuneはINDEスタックに含まれない。
TegraのようにOpenCVを提供している(現在はベータ)。INDEはIntelの他の開発ツール、OpenCL SDKやIPP、TBB等も統合されている。またIntel C++ CompilerがGPUオフロードに対応した( http://www.xlsoft.com/jp/products/intel/compilers/ccw/2015/Release_Notes.pdf )。
NVIDIA同様、IntelもOpenGL ESエミュレータやシェーダコンパイラ、シェーダアナライザは提供していない。OpenCL SDKはSPIRをサポートする等それなりに充実している。

AMD

AMDはモバイル向けではあまり成功を収めていないため、モバイル向けの明確なSDKは無い。CPU/OpenCLのデバッガにはCodeXLが提供されており、AMD CPU上では固有のパフォーマンス測定機構(IBS/PMC)を使用しての解析も行える。
GPUに関してはGPU PerfStudioがフレームデバッガを含んだ一般的なGPUパフォーマンス解析機能を提供しており、GPU ShaderAnalyzer for GCN( http://developer.amd.com/tools-and-sdks/graphics-development/gpu-shaderanalyzergcn/ )がGCNコアに固有の解析機能を提供している。GCNはPS4/XboxOneでも採用されているGPUコアであり、コンソール界隈ではどうしても意識する必要のあるコアとなっている。
OpenCLはAMD APP SDKが従来通り提供される( http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/ )。また、APP SDKはOpenCVも提供している。
ちなみにAMDはGPU仕様の公開を続けていて、Linuxカーネルにamdgpu DRM バックエンドを追加したことでLinuxカーネルのパッチサイズを過去最大にした。

The reason for that huge number of lines is largely a single source:
the bulk of this by far is from the new amd gpu register description
headers. In fact, just those register descriptor headers alone are
about 41% of the entire patch. The rest of the new amdgpu driver
itself is another 8% of the total, so we're in the somewhat odd
situation where a single driver is about half of the whole rc1 in
number of lines.

このregister descriptorは:

一つあたり1MiBを越える凄まじい量になっている。

NVIDIA

NVIDIAは自社の開発環境ポートフォリオをGameWorksに統合した。特に、Tegra専用の開発環境であったTADP(Tegra Android Developer Pack)は発展的に解消し全てのAndroid環境で使用できるAndroidWorksに移行した。このため、NVIDIAは無料でVisualStudio向けのGDBプラグインを配布していることになる。ただし、名称はNsight Tegraのまま( https://developer.nvidia.com/nvidia-nsight-tegra )となっている。
AndroidWorksにはGPUツールも含まれるが、これは従来通りNVIDIA Tegraのみのサポートに留まっている。
クロスプラットフォームGamePad APIのような絶妙なポジションのライブラリ(ソースコード提供)も配布している( https://developer.nvidia.com/cross-platform-gamepad-api )が、反面スマートフォン向けSoCからは撤退する( http://pc.watch.impress.co.jp/docs/column/kaigai/20150707_710516.html )等絶妙な選択を迫られている状況に見える。
NVIDIAのSDKには未だにOpenGL ESエミュレータやオフラインコンパイラ、オフラインシェーダアナライザが無い。基本的に実機指向と言える。Unifiedシェーダ移行前のGeForceコアベースのTegra(4以前)のサポートは大幅縮小していて、新しい開発ツールはK1やX1以降用に制作されている。おそらく、IntelのようにPC/Mobileで統合された開発ツールを提供する方向を目指すのではないだろうか。

Qualcomm

Qualcommは、元ATIから買収したAdreno(並び替えるとRadeonになる)のSDKをAdreno GPU SDKとして提供している。SDKにはテクスチャツール等が一通り含まれるがオフラインシェーダコンパイラは廃止された。Adrenoのドライバはシェーダバイナリのキャッシュをサポートするためにコンパイル後のバイナリを取得できるが、オフラインでの生成は不可能になった。
また、OpenCLデバッガが追加されたが、デバッガコアとしてLLDBを採用している。LLDBはLLVMプロジェクトのデバッガで、他にはXcode等で採用されている。
エミュレータ等が提供されているのは従来通り。また、VisualStuio向けのCPUデバッガも他社同様に提供している( https://developer.qualcomm.com/software/snapdragon-debugger-visual-studio )。NVIDIA同様、Snapdragonなデバイスであることは要求していない。

ARM

ARMはこれといって大きな動きはなく、継続的に新IPをサポートしている。オフラインシェーダコンパイラは遂にOpenCLのビルドもサポートした。SDKの構成も変わりはなく、オフラインコンパイラとかエミュレータを個々にアップデートする必要がある。
ARMはGeometricsを買収するなどゲーム関連分野の強化を継続している。また、各ツールは未だにMali-400のようなローエンドコアをサポートしている。
ARMは典型的な組込みGPUツールセットを提供していると言えるが、Qualcommがオフラインシェーダコンパイラの提供を止めてしまったり、ATSCが標準になるなどGPUベンダのオフラインテクスチャツールの重要性が低下する等の流れのなかで、典型的なGPU SDKベンダはARMとIMGくらいになってしまった。

IMG

Intelがローエンド製品にまで自社のグラフィックスコアを採用し、AppleがPowerVRの看板を降ろしつつある今、一番岐路に立たされているGPUベンダImagination Technologies。SDKとしてはそれなりの歴史と充実を誇っている。
Series6からは、アセンブラ命令セットもドキュメントされているものの、これはシェーダ命令セット自体ではなくGPUアセンブラとして利用できるレベルの情報でない。
SDKは未だにSeries5をサポートしている。このため、ARM同様GLES2.0をサポートしたIPであれば市場のデバイスはほぼカバーしている。MBXのようなGLES1系のIPは最早言及すら無い。

Vivante

特に動き無し。 ...マジで？
Freescaleは自社のi.MX7ではGPUを採用せず、コンポジションのみの提供に留めてしまったので、VivanteのSDKであるVDKを公開するベンダが無くなってしまった。
VivanteもDMP同様極小GPUコア(nanoシリーズ)を提供開始している。

傾向と対策

もともとこの調査はteslawire用に用意している自前のゲームエンジンとGPUベンダのSDKをどうやって統合するかを考える過程で出てきたもので、いろいろと見て回った結論は:

  • 各社のGLESエミュレータとの統合は提供する。オフラインシェーダコンパイラが無くても、エミュレータがバリデーションを提供しているケースが有る(Qualcomm)。
  • パフォーマンス解析は実機じゃないと無理。エンジン側にリプレイを設けて自動テストできるように考える必要がある。パフォーマンスカウンタを統合するためのAPIを提供しているケースも有る(AMD/NV/IMG)。
  • テクスチャ圧縮はどうにもならない。テクスチャパックを作って後で配布する..? それだとQAが大変すぎる。。

というあまり夢の無い結論に。。