Direct3D 11のCPUからフレームバッファにアクセスする方法は？

Question

私はC++/D3D11の基本的なグラフィックスの概念を教えるためのシンプルなフレームワークを作成しています。このフレームワークは、単純なインタフェース機能（例えば、Putpixel(x,y,r,g,b)）を介してスクリーンラスタコンテンツの直接操作を可能にすることが要求される。

D3D9では、CPUがサーフェスを構成するヒープにサーフェスバッファを割り当てることで、これは比較的簡単な目標でした。次に、バックバッファがロックされ、ヒープバッファの内容がバックバッファに転送されます。私が理解しているように、D3D11のCPUからバックバッファに直接アクセスすることはできません。テクスチャリソースを準備し、それをいくつかのフルスクリーンジオメトリを介してバックバッファに描画する必要があります。

私は、このような手順のために2つのシステムを考えました。第1のものは、D3D11_USAGE_DEFAULTテクスチャとD3D11_USAGE_STAGINGテクスチャとを含む。ステージングテクスチャは、最初にマップされ、CPUから描画されます。シーンが完成すると、ステージングテクスチャはマップされず、CopyResource（GPUを使用して誤っていない場合はコピーを実行）のデフォルトテクスチャにコピーされ、デフォルトのテクスチャがフルスクリーンのテクスチャ付きクワッドを介してバックバッファに描画されます。

第2のシステムは、D3D11_USAGE_DYNAMICテクスチャと、ヒープ上に割り当てられたフレームバッファとを含む。シーンが合成されると、ダイナミックテクスチャがマップされ、ヒープバッファの内容がCPUを介してダイナミックテクスチャにコピーされ、ダイナミックテクスチャはマップされず、フルスクリーンテクスチャ付きクワッドを介してバックバッファに描画されます。

私は、読み書きアクセスで作成されたテクスチャとD3D11_USAGE_STAGINGがシステムメモリに存在するとの印象を受けましたが、実行したパフォーマンステストはそうでないことを示しています。つまり、CPUを介して単純な200x200の塗りつぶし矩形を描画すると、ステージングテクスチャがヒープバッファよりも約3倍遅くなります（両方のケースで正確に同じ逆アセンブリ（タイトなrep stosループ））ので、ステージングテクスチャがグラフィックスアダプタメモリ。

これは、バックバッファへのレンダリングとシステムメモリからGPUへのグラフィックスメモリへのコピー作業の両方を可能にするので、ステージングテクスチャシステムを使用することをお勧めします。しかし、私はそのような能力を超えてCPUアクセス速度を優先させたいと思っています。

この方法の場合、どのような方法が最適ですか？どんなヒント、私の2つのアプローチの修正、または全く異なるアプローチの提案も大いに感謝されます。

Answer 1

ダイナミックとステージングは​​どちらもシステムメモリ内にある可能性がありますが、その問題は、結合メモリを書き込む可能性が高いです。これは、単一の書き込みが合体するキャッシュモードですが、キャッシュされていないために読み込みを試みると、各読み込みは完全なメモリアクセスの代償を払います。 C++ *data=something;はまた、望ましくない読み込みを招くこともあるので、非常に注意する必要があります。

ダイナミックテクスチャには何も問題はありませんが、GPUはシステムメモリを読み取ることができますが、注意して作成し、いくつか作成し、map_nooverwriteで各フレームを循環させる必要があります。捨てる。もちろん、読んだり書いたり、書いたりするだけでマップを作ったり、gpu/cpuのシンクを導入したりして並列性をなくすことはありません。

最後に、永続的なサーフェスとフレーム（またはそれらの多く）のほんのわずかなputpixelが必要な場合は、色の付いたピクセル位置のバッファを消費する順序付けられていないアクセスビューと計算シェーダを使用します更新。そのバッファは、上書きマッピングを伴わない動的バッファになります。このソリューションでは、メインサーフェスはビデオメモリに常駐します。

個人的には、私はCPUの表面操作を教えても気にしませんでしたが、これは現代のGPUアーキテクチャに移行する方法ではなく、ほとんど常に悪い練習であり、パフォーマンスキラーです。これはすでに10年前の基本的なグラフィックコンセプトではありませんでした。