12」を正式に発表した。11が発表されたのは2009年。7とほぼ同時期にリリースされたことを憶えている人もいることだろう。11.2がリリースされているが,メジャーバージョンアップとしては本当に久しぶりということになる。現地時間20日,朝一発めのセッションであるにもかかわらず,会場はオープン前から長蛇の列ができた。「GPUの性能はどんどん向上している。CPUは,1コアあたりの性能向上率はそれほどでもなくなっている一方,CPUのコア数自体は増加傾向にある。そんな状況にあって,ゲーム開発者は一体何を欲しているのか」。12の開発は,この問いかけが起点になっているという。今日(こんにち)のプロセッサ技術トレンドは,「コア数増大」方向に舵を切っている。Gosalia氏によれば,ゲーム開発者が強く求めているものの1つに,ゲーム機ライクな「GPUを直接ドライブ(≒駆動)できるようなAPI」があったとされる。切望されるもう1つの要素が,「ゲームアプリケーションとGPUの間のオーバーヘッドを極力なくすこと」だったそうだ。12であると位置づけていた。12を基本的に区別しない。この点はご了承のほどを。12だが,結論からいうと,実効パフォーマンスを改善する目的のアーキテクチャ改変がアップデートの中心となっている。「Direct」(ダイレクト)と言いながら,あまりダイレクト感がなくなってきたDirectXに,近代流のダイレクト感を持ち込もうとする方向の改変なのだ。DirectXが誕生した1990年代中期は,さまざまなメーカーがそれぞれ独特なアーキテクチャに基づくGPUを用意しており,そして,そこには機能差もあったことから,“違い”を吸収するための抽象化レイヤーを分厚くする必要があった。当時のGPUは,データやパラメータを与えて「GPUの機能を呼び出す」というプログラミングモデルだったこともあり,ゲームアプリケーションとGPUまでの“距離感”が相当に大きかった,という表現も可能だろう。現在,PC向けGPUのメジャープレイヤーはIntelとNVIDIA,AMDの3社のみであり,モバイルデバイスや組み込み機器向けGPUですらも,3社いずれかのアーキテクチャに似た構造となった。ような分厚い抽象化レイヤーはもはや必要なくなってきている。そこでMicrosoftは,1990年代に構築された古い土台をすべて取り去って,すっきりした透明性の高いアーキテクチャへと,DirectXを改変することにしたのである。12を提供する計画があると今回明らかにしており,グラフィックスAPIを一気に刷新する心づもりでいる。一時期は「DirectXはもう終わり」とまことしやかに囁かれるほどだったが,ここで心機一転の再スタートを図ろうということなのだ。APIを通じてパラメータをドライバに受け渡し,ドライバ側がGPUに向けて(描画)コマンドとパラメータ列を形成して発行する」構造になっているが,ここに問題が2つある。1つは,DirectXが提供している「APIを利用してDirectX側が作り出すコマンドとパラメータのペア」が,GPU内部のハードウェアを直接ドライブするようにはなっていない点だ。これは,「DirectXのアーキテクチャが古すぎて,実在する最新世代のGPUアーキテクチャとかけ離れすぎてしまった」と考えれば分かりやすいだろうか。Object」(以下,PSO)という概念だ。詳細は後日あらためてお伝えしたいと思うが,誤解を恐れずに簡略化して言うと,PSOというのは,グラフィックスパイプラインとGPU内部ハードウェアとの対応を一意的に定義づけて利用する仕組みのこと。PSOを定義づけておけば,それ以降はGPUに対し「これからお願いする描画は,PSOで定義した工程表(パイプライン)ベースでお願いします」と発注できる。従来のDirectXでは「頂点シェーダでこの処理を行う」「ピクセルシェーダでこの処理を行う」といった感じの,細切れな指示になっていたため,処理のストール(stall,停止)が生じやすかった。その点PSOなら,GPUはあらかじめ定義された工程表に基づいて,すぐに処理に取りかかれるのである。1つは,コマンドを伝送する仕組みそのものの問題だ。従来のDirectXでは,APIを通して,「描画の件なんですがね」「第一パラメータは●●です」「第二パラメータは××です」といった感じに,コマンドを逐次的に発行していた。砂時計にたとえるなら,上がCPU,下がGPUで,上下は大きく開いているのに,中央部がぎゅっとすぼまったイメージ。砂粒(≒仕事)は1本の線状でしか,GPUのほうに落ちていかないのである。12では,あらかじめ確保しておいたメモリバッファ上で描画コマンドやパラメータを形成しておき,これをドライバへ一気に渡せるようになった。メモリバッファ上に描画コマンドやパラメータを形成する処理は複数のCPUスレッドで並列に実行できる。マルチスレッドを効果的に利用できるということだ。砂時計でいえば,中央のすぼまった部分が押し広げられたようなイメージだろうか。12における根幹的な進化ポイント。オーバーヘッドを減らし,大量に仕事を発注できる仕組みを実装したという感じ「ドライバを通じてGPU側に伝送される前の描画コマンド」はドライバ側でGPUのネイティブ命令に変換されるので,ここにまだ抽象化レイヤーは存在することになるが,まとまった量の描画コマンド列を一気に発行できる以上,効率は従来比で格段に改善する。12では,この「GPU側で直接実行できるように変換されたネイティブコマンド列」を保存しておける仕組みも導入された。これは「Bundles」(バンドル)と呼ばれ,そのままBundlesを再発行してGPUを駆動することもできる。うまく活用すれば,抽象化レイヤーを超えた先で,超高効率でGPUをドライブすることも可能なのだ。12では抽象化部分はものすごく薄く設計されている。すべてのメーカーのGPUに対応する必要があるため,最低限の抽象化部分は残っているが,その抽象化を超えた先でのGPUドライブの仕組みも提供される。12の大きな進化ポイントといえるだろう。Mantle的とも言えるがまた,テクスチャや各種データテーブルなどといった,レンダリングに必要な素材を,アプリケーション側が任意のスタイルでその素性を定義しつつグラフィックスメモリ上に置き,実際のレンダリング時には各種シェーダから自由にアクセスする仕組みも新設されている。DirectXのAPIを介して「これはテクスチャです」としていちいち宣言したり定義したりすることなく,かなりのダイレクト感をもって,グラフィックスメモリ上にデータや素材を自在に置けるようになったのである。CPUのプログラムにおいて,当該プログラムの開発者は,プログラム実行の各局面に応じて,確保したメモリ空間を好きに使っていた。いった自由なメモリの使い方がGPUでもできるようになったことになる。これは,家庭用ゲーム機のGPUプログラミングでは結構前からそうだったので,概念的に新しいものではない。12が,家庭用ゲーム機的なGPUプログラミング哲学を取り入れたという認識のほうが正しいので,この点は押さえておく必要があろう。素材やリソース周りの取り扱いの改善ポイント。12のβ版は2014年後半リリース。12にはどの程度の性能を期待できるのか。12に対応させて動作させたものとで,CPU負荷に違いが出るかどうかが披露された。11では,4つあるCPUスレッドのうち1つで極端に負荷が高くなっている。12では,CPU負荷が極端に低い。