GPU を使用して 1 つの複雑なアルゴリズムを実装しようとしています。唯一の問題はハードウェアの制限であり、利用可能な最大機能レベルは 9_3 です。
Algorithm は、基本的に 2 つの画像の「ステレオ マッチング」のようなアルゴリズムです。前述の制限により、すべての計算は Vertex/Pixel シェーダーでのみ実行する必要があります (使用可能な計算 API はありません)。ここでは頂点シェーダーはあまり役に立たないので、パススルー頂点シェーダーと見なしました。
アルゴリズムについて簡単に説明します。
2 つの画像を取得し、コスト ボリューム マップを計算します (基本的に、RGB をグレースケールに変換 -> 右の画像をDで変換し、左の画像から減算します)。このステップは、 Texture3D を生成するさまざまなDに対して約 20 回繰り返されます。
ここでの問題:ピクセル シェーダーのサイズ制限 (最大 512 演算) のため、これらの 20 回の繰り返しを一度に計算する 1 つのピクセル シェーダーを単純に作成することはできません。すべての操作が同じ 2 つのイメージに対して行われている間、CPU -ここに 1 つのボトルネックがあるように思えます。複数のレンダー ターゲットがあることは知っていますが、最大数があります。8 つのターゲット (20 以上が必要)。1 つのピクセル シェーダーで 8 つの結果を生成したい場合は、サイズ制限 (HW で 512 演算) を超えます。
次に、r > 9 のウィンドウで計算されたテクスチャ ボックス フィルターのそれぞれについて計算する必要があります。
ここでのもう 1 つの問題:ウィンドウが非常に大きいため、ボックス フィルタリングを 2 つのピクセル シェーダー (垂直方向と水平方向に別々に) に分割する必要があります。これらのループを手動で実装しても、大きなピクセル シェーダーが作成されるため、役に立ちません。したがって、ここでもう 1 つのボトルネックです。CPU を使用して、一時テクスチャ (V パスの結果) から 2 番目のパス (H パス) に結果を渡す必要があります。
次に、次のステップで、1 番目のステップと 2 番目のステップの結果の各ペアに対していくつかの算術演算が適用されます。
私は自分の開発でまだここに到達していないので、ここでどのようなボトルネックが私を待っているのかわかりません.
次に、ステップ 3 のピクセル値に基づいて、各ピクセルの最小 D (最初のステップのパラメーターの値) が取得されます。
... 手順 3 と同じ。
これは基本的に、現在の実装を示す非常に単純なグラフです (ステップ 3 と 4 を除く)。
赤い点/円/何でも、部分的な結果が保存され、すべての赤い点で CPU が関与する一時的なバッファー (テクスチャ) です。
質問 1: CPU を巻き込んでボトルネックにならずに、各分岐フォームを最後まで実行する方法を GPU に知らせることはできないでしょうか? つまり、一連のグラフィックス パイプラインを一度にプログラムしてから、GPU にその仕事を任せます。
render-to-texture に関するもう 1 つの質問: すべてのテクスチャは、Draw() メソッドの呼び出しと Pixel/Vertex シェーダーの切り替えの間でも、常に GPU メモリに存在しますか? または、GPU から CPU への転送が発生しています...これはボトルネックにつながる別の問題である可能性があります。
どんな助けでも大歓迎です！
前もって感謝します。
よろしく、 ルカシュ