3月20日、GDC 2014カンファレンスの枠組みの中で、DirectX 12の次のバージョンの発表が行われ、DirectXDはDirectXの主要なコアであり、ゲームアプリケーションの最も重要なコンポーネントが作成されます。 開発チームはDirect3Dに多くの変更を加え、その結果、多くのグラフィック操作の速度と効率が向上しました。 これらの変更により、より詳細なシーンを作成し、最新のGPUの機能を最大限に活用できます。 しかし、これらの機能は、ハイエンドのゲーミングコンピューターだけでなく登場します。 Direct3D 12は、すべてのMicrosoftデバイスで動作します。 携帯電話、タブレット、ラップトップ、デスクトップ、そしてもちろんXbox One。これらすべてでDirect3D 12 APIを使用できます。
Direct3D 12が以前のバージョンより優れているのはなぜですか？ 何よりもまず、これは機器の抽象化のレベルが低いことです。 これにより、ゲームはスレッドスケーラビリティとGPU使用率を大幅に改善できます。 さらに、ゲームは記述子テーブルとパイプライン状態オブジェクトの恩恵を受けます。 これだけではありません。Direct3Dには、レンダーパイプライン用の一連の新機能が含まれており、透明度の計算、衝突検出、および幾何学的除去の効率を大幅に向上させることができます。
言うまでもなく、APIを活用するのに役立つツールがある場合にのみ、APIは優れています。 DirectX 12には、DirectX 12のリリース後すぐに、Direct3D用の多数の優れたツールが含まれます。
はい、忘れないでください-DirectX 12は多くの既存のグラフィックスカードで動作します。
これはマーケティング策略ですか？
開発チームはTwitterやフォーラムで多くのコメントを読みました。そこではよく質問されます。それは本当に技術的な更新なのですか、それともマーケティング部門が新しいインデックスをバージョンにプロモートする予算を得たのでしょうか？ 以下を読むすべては、DirectXを20年間開発してきたチームから直接得たものです。
APIを作成するのは私たちの仕事であり、Direct3D 12のパフォーマンスの大幅な改善を証明するために、パートナーのソフトウェアおよびハードウェアメーカーと協力しました。Direct3D12に含まれるこれらの新製品は、マイクロベンチマークのハックではありません。 受け取った数値は、商用ゲームとアルファ版でテストされた認定ベンチマークに基づいています。 表示されるスクリーンショットは、ランタイムとDirect3D 12ドライバーを実際に実装した実際のDirect3D 12アプリケーションで作成されたものです。
3DMark-インラインスケーリング+ CPU使用率の50％
あなたが熱心なゲーマーなら、おそらく3DMarkについて知っているでしょう。 これは、幅広いデバイスとハードウェアのパフォーマンスを評価するための優れたツールです。 Direct3D 11で実行されている3DMarkでは、ストリームスケーリングを使用できますが、ランタイムとドライバーに関連付けられた一部のオーバーレイにより、スレッドとコアのアイドル待機時間があります。 3DMarkをDirect3D 12に移行した後、CPU使用率が50％増加し、スレッド間の作業の分散が改善されたという2つの重要な改善が見られました。
Direct3D11 
Direct3D 12
Forza Motorsport 5技術デモ-PCでのコンソールパフォーマンス
Forza Motorsport 5は、XboxOneを最大限に活用するゲームの例です。 Forzaの内部には、コンソールのグラフィックスサブシステムとやり取りするための低レベルAPIがあります。 従来、このレベルの有効性は、統一されたハードウェアでのみ達成可能です。 現在、そのような機会は、アルファ版であっても、コンピューター上、さらには電話上にあります。 Direct3D 11.1に基づいてグラフィックコアコードを移植する際、Turn 10チームはDirect3D 12の機能のおかげで、PC上で同じレベルの最適化を達成しました。
このパフォーマンスはどこから来たのですか？
Direct3D 12は古いDirect3D 11プログラミングモデルから遠ざかりつつあり、アプリケーションをこれまでになくハードウェアに近づけることができます。 重要なAPIエリアは、パイプラインの状態を表すメカニズム、タスクの送信方法、リソースへのアクセスなどの重要なものです。
パイプライン状態オブジェクト
Direct3D11を使用すると、多数のクロスオブジェクトを介してパイプラインの状態を操作できます。 たとえば、入力アセンブラーの状態、ピクセルシェーダーの状態、ラスタライザーの状態、および出力ミキサーの状態、これらはすべて独立して変更できます。 このメカニズムは、グラフィックスパイプラインの便利で比較的高レベルのプレゼンテーションを提供しますが、残念ながら、最新のハードウェアにはあまり適していません。 まず第一に、多くの州の間には相互依存関係があるという事実のため。 たとえば、多くのGPUは、ピクセルシェーダーと出力ミキサーの状態を1つのハードウェア表現に結合します。 Direct3D 11 APIを使用すると、状態を個別に変更できますが、ドライバーは、状態が終了したことを認識するまでそれを解決できません。これは、レンダリングの開始まで不可能です。 これにより、鉄の状態の設定が遅れることになります。つまり、コストがかかり、フレームあたりの描画呼び出しが少なくなります。
Direct3D 12では、パイプラインの状態のほとんどをパイプラインの状態の不変オブジェクト（OSK）に統合することでこの問題を解決できます。これは、作成直後に修正されます。 これにより、ハードウェアとドライバーはOSKをすぐに適切なハードウェア命令に変えることができ、GPUが機能するには状態が必要です。 この場合、使用したいOSKを動的に選択できます。 現在では、ハードウェアの状態をオンザフライで計算するのではなく、以前に計算した少量の状態をハードウェアレジスタにコピーするだけです。 これは、描画呼び出し間のオーバーヘッドが大幅に少なくなり、フレームごとの描画呼び出しが増えることを意味します。
パッケージとチームリスト
Direct3D 11では、すべてのジョブは即時コンテキストを使用して送信されます。即時コンテキストは、GPUに送信されるコマンドセットを表します。 ゲームのパフォーマンスのマルチスレッドスケーリングには、遅延コンテキストが使用されますが、OSKの場合のように、遅延コンテキストはハードウェアの実際の状態に対応していません。
Direct3D 12は、コマンドリストに基づいてタスクを送信するための新しいモデルを提供します。 GPUでの実行に必要なすべての情報が含まれています。 コマンドのリストには、OSK、テクスチャ、バッファリソース、描画コマンドの引数が含まれます。 コマンドのリストは自律的であり、状態を含まないという事実により、ドライバーは独立したフローで必要なGPUコマンドを事前に計算できます。 必要なのは、コマンドリストを介してコマンドリストをGPUに最後に送信する際のシリアル化プロセスだけです。このプロセスは非常に効果的です。
コマンドリストに加えて、Direct3D 12には、パッケージを使用するセカンダリ事前計算メカニズムが含まれています。 完全に自律的なコマンドのリストとは異なり、通常は作成され、実行のために送信されてから破棄されるコマンドのリストとは異なり、パッケージは何らかの形で状態に依存せず、再利用を伴います。 たとえば、ゲームが異なるテクスチャの2つのキャラクターモデルを表示する必要がある場合、1つのアプローチは、同一の描画呼び出しの2つのセットでコマンドのリストを記述することです。 別のアプローチは、1つの文字を描画する1つのパッケージを記録し、異なるリソースを使用してコマンドのリストでパッケージを2回「巻き戻す」ことです。 後者の場合、ドライバーは命令を1回だけ計算する必要があり、コマンドのリストを作成することは基本的に2つの低コストの関数呼び出しに相当します。
ヒープ記述子とテーブル
Direct3D 11のリソースバインドは抽象化されており、非常に便利ですが、同時に、最新のハードウェアの機能の多くは機能していません。 Direct3D 11では、ゲームは「ビュー」オブジェクトを作成し、パイプラインのシェーダーのさまざまな段階でこれらのビューを「スロット」にバインドします。 シェーダーは、これらの明示的にアタッチされたスロットからデータを読み取り、レンダリング時に修正されます。 このようなモデルは、ゲームが異なるリソースセットを使用してレンダリングを行う必要がある場合、ビューを他のスロットに再リンクしてレンダリングを呼び出す必要があることを意味します。 これは、鉄の最新の機能を完全に使用する場合に排除できるオーバーヘッドの別の例です。
Direct3D 12は、最新の機能に合わせてバインディングモデルを変更し、生産性を大幅に向上させます。 Direct3D 12は、自律的なリソース表現とスロットへの明示的なバインドを必要とする代わりに、ゲームが独自のリソース表現を作成する一連の記述子を提供します。 このメカニズムにより、GPUはリソース記述のハードウェア表現をメモリに直接事前に書き込むことができます。 特定の描画呼び出しのパイプラインでどのリソースが使用されるかを宣言するために、ゲームは記述子の完全なヒープのサブ範囲を表す1つ以上の記述子テーブルを示します。 このヒープには必要なハードウェア固有のデータがプリロードされているため、記述子テーブルの変更は非常に安価な操作です。
ディスクリプタヒープとテーブルに関連する改善に加えて、Direct3D 12ではシェーダーのリソースに動的にインデックスを付けることができます。 これにより、これまでにない柔軟性が提供され、新しいレンダリング技術への道が開かれます。 たとえば、遅延アプローチに基づく最新のレンダリングエンジンは、多くの場合、マテリアルまたは何らかのタイプのオブジェクトの識別子を予備のgバッファにエンコードします。 Direct3D11では、多くのgバッファーを含めると最終レンダリングパスの速度が大幅に低下する可能性があるため、このようなエンジンは非常に多くのマテリアルの使用に注意する必要があります。 動的にインデックス付けされたリソースと一緒に、1,000のマテリアルを含むシーンを10の場合と同じくらい迅速にファイナライズできます。
最初の人になりたいですか？
あなたがプロのゲーム開発者であり、Direct3D 12がアプリケーションのパフォーマンスを高速化することを期待している場合は、予備的な馴染みプログラムを申請できます。