状況：
計算と画像のレンダリング (画像の前処理と表示) の両方が必要なアプリケーションでは、AMP と WPF の両方を使用したいと考えています (AMP は画像に対していくつかのフィルターを実行し、WPF はスケーリング/回転された表示以上のことはしません)。どちらも約 30 fps で実行され、新しい画像が継続的にストリーミングされます)。
質問：
2つが互いにどのように影響するかを知る方法はありますか?
後で実際のアプリケーションでも、分離された AMP のみの環境で見られる、うまくいけば素晴らしいスピードアップが見られるかどうか疑問に思っています。
追加情報：
とにかく別のプロジェクトでセットアップするのは低レベルで新しい機能であるため、AMP のパフォーマンスを個別に測定することができます。複雑なアプリケーションでは WPF レンダリング部分が既に存在するため、それを分離することは困難です。
結果は中間レベルでも必要になるため、レンダリングのみにフィルターなどを実行する予定はありません (エッジ検出、保存などの他のアルゴリズム)。
ここで考慮すべき点がいくつかあります。
2つが互いにどのように影響するかを知る方法はありますか?
直接的にはいいえですが、間接的にはそうです。WPF と AMP の両方がレンダリングに GPU を利用しています。アプリケーションの AMP 部分が GPU のリソースを使いすぎると、フレーム レートに干渉します。C++ AMP ブックのCartoonizer のケース スタディでは、 MFC と C++ AMP を使用して、説明したとおりに実行します。画像処理の負荷が高い低速のハードウェアでは、アプリケーションの応答性が低下することがわかります。ただし、ほとんどの場合、GPU で画像を漫画化する方がはるかに高速で、ビデオ フレーム レートを達成できます。
うまくいけば素晴らしいスピードアップが見られるかどうか疑問に思っています
どの GPU アプリケーションでも、パフォーマンスの向上を確認するための鍵は、CPU ではなく GPU で計算を実行することによるスピードアップが、GPU との間でデータをコピーする追加のオーバーヘッドを補う必要があるということです。
この場合、ネイティブ (C++ AMP) からマネージド (WPF) 環境にデータをマーシャリングする必要があるため、追加のオーバーヘッドがあります。データ型が blitable であり、明示的なマーシャリングを必要としないことを確認して、これを効率的に行うように注意する必要があります。WPF とネイティブ コードを使用したN 体モデリング アプリケーションを実装しました。
理想的には、GPU 計算の結果を CPU 経由で移動せずにレンダリングする必要があります。これは可能ですが、明示的に WPF を使用する場合はできません。N-body の例では、DirectX レンダー エリアを WPF に直接埋め込み、AMP 配列から直接データをレンダリングすることでこれを実現しています。これは主に、WPF viewport3D が私のパフォーマンス ニーズを実際に満たしていなかったためです。イメージのレンダリングには WPF が適している場合があります。
VS 2013 で状況が変わっていない限り、C++/CLI プロジェクトでネイティブ コードを使用する場合にはいくつかの制限があるため、C++ AMP コードを別の DLL に入れる必要があります。
@stijn が提案するように、小さなプロトタイプを作成して、計算の一部を GPU に移動することで得られる利益が、GPU との間だけでなく WPF にもデータを移動するオーバーヘッドのために失われないようにします。