• Flat でシンプルなメモリモデル
• マルチスレッド対応の Multiple Command Buffer
• 描画 API の CPU overhead が小さくなり大量の Draw Call が可能になる。

負荷が小さくより低レベルで Game Console に近づく。

• Draw 命令の負荷が高く何度も描画することができない。
  • PC における 3D 最適化の基本は Draw 命令の回数を減らすことだった。
  • オブジェクトの統合、DrawInstance 命令の活用など

• ステート設定が細切れであり描画命令発行時まで確定しない
  • ステート設定 API は、データを一旦メモリにコピーして保存する必要がある
  • Draw 命令時に必要な変更されたステートを集めてハードウエアに送る必要がある。ステート値は比較した後再びメモリコピー

Draw 命令の負荷が非常に高くなる。ステートなどの情報を何度もメモリコピーしなければならない。 Draw 命令の負荷が高いために何度も Draw を呼び出すことが出来ない。

• コマンドバッファとは、描画時に GPU が実行するコマンド列のこと
  • 描画 API を呼び出すと、ドライバは GPU 毎に必要な命令を生成してコマンドバッファに追加する。
  • いわば、汎用描画 API を、その都度ネイティブな GPU 命令にコンパイルしているようなもの

• これまでの描画 API は毎フレーム同じ描画であっても、毎回コマンドバッファを作り直す必要があった
• Game Console との大きな違いの一つ。
  • 多くの場合 Game Console は、一度生成した Command Buffer を再利用できる。
  • また GPU Native な Command Buffer を事前に作っておくことも可能。変換が不要なので非常に CPU 負荷が小さくなる。

• Draw Call 負荷が低く以前よりも大量に Draw 呼び出しができるようになる。
  • Draw Call 回数に対する最適化の必要性低下
  • ゲーム専用機からの移植が容易
  • 2D UI 描画のような細かいパーツが多い場合にもおそらくメリットがある
• CPU 負荷が下がるため、より他のタスクに割り当てることができる。相対的に CPU 性能が上がる。
• 最初からスレッド並列化を考慮しており、現在の CPU 構成に見合った使い方ができる。
• メモリ管理がユーザーに委ねられており、リソースの無駄なコピーを減らす等の最適化や工夫が可能になる
  • 従来はドライバで隠れていた部分も、ユーザー側で更に最適化できる余地がある
• 自由度の向上
  • フラットなメモリ管理で API 上の制限が無くなります。例えばリソース数、バインド可能なバッファ数など (GPU依存)

• 低レベル化 (Low Overhead) とは離れるが、新規に設計した API なので互換性など過去のしがらみがない
  • 肥大化した古い仕様を切り捨てることができる。互換性のためだけに残っていた制約がなくなる。シンプル化
  • 最新のハードにとって都合の良い仕様に変更できる

• 新機能
  • API によりますが新しい GPU 機能をサポートしています。もちろん GPU 側の対応も必要です。

• CPU オーバーヘッドを減らすために低レベル化している
  • バッファ管理と転送
  • シェーダーレジスタとのリソースバインド
  • バッファ間の同期やキャッシュの制御
  • コマンドバッファの明示的な生成と発行

これまでドライバが自動的にうまいこと管理してくれていた部分まで、自分でやる必要が生じます。 特に複数のプロセッサから同時にアクセスされるメモリやキャッシュの仕組みを考慮しなければなりません。 API の設計次第ですが、例えばレンダーターゲットを次の描画でテクスチャとして参照する場合は同期命令が必要です。

Game Console (専用機) は最初から API の overhead が小さいため、これらの API を採用しなくても十分パフォーマンスが出るように作られています。 そのため、Game Console がこれらの新しい API を採用する必要性は特にないでしょう。 ただし対応することで PC や Mobile デバイスとの互換性が取りやすくなるメリットがあります。

またパフォーマンス的な差が小さくなるので、専用機に対する敷居が下がります。 たとえば Linux や Android を使っても、今まで以上に性能を引き出せるゲーム端末を簡単に作れるようになるでしょう。

• DirectX/Vulkan の場合は API / SDK だけでなく、GPU ドライバの対応を待つ必要があるので GPU によって使える時期は異なります。

これまでの Direct3D 8 → Direct3D 9 → Direct3D 10 → Direct3D 11 のような GPU の進化に沿った拡張ではないのが今回の最大の特徴です。 CPU を活用するために行われた API とドライバの再設計なので、ハード的な要件はほぼ無いと言って良いでしょう。

現在使われている Direct3D 11 世代の GPU でそのまま新しい API が使えます。 ただしハード的に対応が可能だったとしても、ドライバがリリースされるかどうかはメーカー次第です。 ドライバがなければ使うことができません。

特にモバイル向け GPU はユーザーが自由にドライバをインストールできるわけではないので、注意が必要です。

現在 (2014) OpenGL ES 2.0 によって、ほぼすべての Mobile 端末から Web まで高い互換性を保つことができるようになっています。 ところがもし Low overhead API が多く使われるようになると、上記のように対応プラットフォームがばらばらで、再び互換性の問題が生じることになります。

特に iOS の場合は、OpenGL ES 3.0 対応 GPU と Metal 対応 GPU が一致しているので、OpenGL ES 3.0 を用いるメリットが大幅に減少しています。 もしかしたら OpenGL ES 3.0/3.1 はあまり普及することがなく、別の新しい API に取って代わられることになるかもしれません。

• OS: Windows
• GPU
  • RADEON GCN 専用

最初に発表された Low Level API (Low Overhead API) です。 Vulkan のベースとなりました。 RADEON Driver に含まれています。 ただし Windows かつ RADEON GCN 専用なので、今後は Vulkan の使用が推奨されるものと思われます。

• OS: Windows 10
• GPU
  • RADEON GCN
  • GeForce Kepler, Maxwell
  • Intel Haswell, Broadwell, Skylake

• https://msdn.microsoft.com/en-us/library/dn903821(v=vs.85).aspx

Direct3D 11 の後継。 Windows 専用ですが Xbox One も対応します。

ゲーム専用機や Metal とは異なり、同じ低レベル API でも不特定多数の GPU に対応する必要があります。 そのためある程度抽象化されており、低負荷ながら汎用性が重視されています。

GPU 毎にハードの対応度によっていくつかのグループ分けが行われています。 tier1, tier2, tier3 それぞれ、一度にバインド可能な Descriptor 数などリソースの上限に違いがあります。 tier3 に対応している RADEON GCN ではほぼ制限無しにリソースにアクセスできるようです。

既存の多くの GPU で対応しますが新しい機能を活用するには FeatureLevel 12 以上の GPU が必要です。

DirectX 12 (Direct3D 12) の詳細はこちらに追加していきます。

• OS: iOS 8 / OS X 10.11 El Capitan
• GPU
  • Apple A7 (PowerVR G6430)
  • Apple A8 (PowerVR GX6450)
  • Apple A8X (PowerVR GX6850 )
  • Apple A9/A9X (PowerVR)
  • GeForce Kepler以降/RADEON GCN/Intel HD Graphcis Gen7以降 (OS X)

もっとも早く一般公開された低レベル API です。 Apple 独自で特徴は完全新規 API なこと。 互換性の枷が一切ないため非常にシンプルです。

シェーダー言語はただの C(C++) 言語であり、GLSL でも hlsl (Cg) でもありません。 良く知った C++ の構文がそのまま使えるため迷うことが非常に少なくなっています。(厄介で特殊な GLSL の構文を覚える必要がなくなりました!)

これまで iOS/OS X では OpenGL が用いられていたにも関わらず OpenGL の影響は残っていません。 座標系もよりシンプルでハードウエアに近いもの。座標原点は左上で、Z Clip 空間も 0～w です。つまり Direct3D と同じ仕様になっています。

その代わり API は完全に Objective-C (swift) なので、同じコードを iOS/OSX 以外の他の Platform でそのまま流用するのは困難です。

もともと iOS 8 (PowerVR 6 series) 専用でしたが 10.11 (El Capitan) から OS X でも利用できるようになります。 対応している Mac は Mid 2012 以降 (MacPro のみ 2013以降)となります。 GPU でいえば GeForce Kepler 以降、RADEON GCN、Intel HD Graphics Gen7 (IvyBridge) 以降の制限があります。 今までは iOS 端末実機がないと Metal の確認もビルドもできませんでしたが、OS X のサポートにより今後 Mac でも動作確認が可能で Metal 対応アプリが開発しやすくなります。

Metal の詳細はこちらに追加していきます。

• OS: Android / Linux / Windows 7～
• GPU
  • GeForce Kepler, Maxwell, Pascal
  • RADEON GCN (1.0/1.1/1.2/Polaris)
  • Linux: Intel HD Graphics Gen7～ (Ivy Bridge, Broadwell, Skylake, BayTrail, Braswell)
  • Windows: Intel HD Graphics Gen9～ (Skylake)

Khronos の Multi platform API であり、OpenGL の後継となります。 唯一 OS を選ばない Multi Platform API なので、もし広く受け入れられるなら API が統一される可能性があります。 Android が Vulkan を採用することを発表しています。

開発側の立場としては、今後に期待する意味でも、解消されるであろう OpenGL の問題点をあげてみます。

• OpenGL の問題
  • Thread との相性が悪く、Multi Core CPU を活用しづらい。
  • Global な Bind State を経由してアクセスするため、どの API に影響を与えるのか知識がないと理解できない。コードを見ただけではリソースと API の関連がわからない。
  • Desktop API と Mobile API (GLES) が分離している。それぞれ個別に対応する必要あり。
  • Driver に Shader Compiler まで含まれており、GPU メーカーごとに微妙に仕様が異なっている。言語仕様や最適化特性など、ドライバによって違いが生じており、互換性問題の原因となっている。
  • Driver レベルでソースコンパイルを行う関係上、Shader は Source Code を扱う必要あり。毎回コンパイルを行うため、近年の巨大化したシェーダーは起動に時間がかかってしまう。オフラインコンパイルじゃないので最適化に制限がかかる。
  • 歴史がある分だけ互換性問題あり。古い仕様を多数抱え込んでいる。バージョン数も細切れで非常に多い。
  • Driver Layer が分厚く CPU オーバーヘッドが大きい。

• Vulkan の概要
  • シェーダーの共通中間コード SPIR-V の定義。シェーダーバイナリの事前コンパイルが可能。シェーダーコンパイラの統合
  • 低 Over Head
  • その他判明次第追加

Vulkan の詳細はこちらに追加していきます。

• Khronos Vulkan

• OS: 独自
• GPU: 固定

ゲームコンソールは対応するハードウエアが単一なので、Driver が GPU の違いを吸収する必要がありません。 最初から低レベルかつオーバーヘッドが少ない API が提供されています。 その代わり PC/Mobile 向けの汎用 API との互換性がありません。 また同じメーカーであっても、Game Console 毎に OS もライブラリも新規に作られており完全に別物です。 ハードウエアに近い API なので、ハードウエアの世代が変わると互換性を維持することが困難になります。

なお Xbox のように DirectX を採用している場合でも、対応 GPU が単一なのでかなりの最適化が施されています。 PC と比べて非常に軽量です。