2

わかりましたので、GPU と CPU の間の帯域幅を減らす最善の方法を見つけようとしています。

パーティクル システム。

CPUでほとんどのことを事前に計算してGPUに送信する必要があります。これには、位置、回転、速度、アルファの計算、乱数などが含まれます。

または、シェーダーでできる限り多くのことを行い、可能な限りジオメトリ シェーダーを使用する必要があります。

私の問題は、私が作成した種類のアプリでは、たとえば、シェーダーに送信されるいくつかの変数が必要であるということです。ユーザーは、実行時にエミッターの位置と速度に加えて、さらに多くを選択します。どのように対処すればよいかわからないのは、「ユーザーがランダムな速度を必要とし、最小値と最大値を指定してランダム値を選択する場合、このランダム値を CPU で計算して送信する必要がある場合です。 GPU への単一の値として、または最小値と最大値の両方を GPU に送信し、GPU でランダム関数ジェネレーターを使用する必要がありますか?帯域幅の削減と最適化に関するコメントは大歓迎です。

4

2 に答える 2

3

CPUでほとんどのものを事前に計算し、それをGPUに送信する必要がある場合、これには、位置、回転、速度、アルファおよび乱数の計算などが含まれます。

または、シェーダーでできる限り多くのことを行い、ジオメトリシェーダーを可能な限り使用する必要があります。

答えることができません。CPU時間を使いすぎると、パフォーマンスが低下します。GPU時間を使いすぎると、パフォーマンスも低下します。転送するデータが多すぎると、パフォーマンスが低下します。したがって、推測する代わりに（作成しているアプリ、ターゲットハードウェアなどはわかりません。ターゲットAPIとプラットフォームも指定していません）、測定/プロファイルを作成し、最適な方法を選択します。パフォーマンスを推測する代わりにプロファイル。そのためのAQTime7Standard、gprof、およびNVPerfKit（および他の多くのツール）があります。

実際にアプリケーションのパフォーマンスに問題がありますか？パフォーマンスの問題がない場合は、何もしないでください。たとえば、フレームごとにリアルタイムで1,000万個の粒子がありますか？そうでなければ、600MHzのCPUは7年前にそれらの数千を簡単に処理することができたので、心配する理由はほとんどありません。一方、たとえば、動的な3d環境があり、パーティクルがそれと相互作用（バウンス）する必要がある場合、GPUですべてを実行するのは非常に困難になります。

とにかく、私には、何も最適化する必要はなく、実際に最適化する必要はないように思えます。したがって、最善のアイデアは、他のことに集中することです。

ただし、いずれの場合も、頻繁に更新される「動的」データを転送するための正しい方法を使用していることを確認してください。directXでは、D3DLOCK_DISCARD|D3DLOCK_NOOVERWRITEで動的書き込み専用頂点バッファーを使用することを意味しました。OpenGLの場合、これはおそらく、DRAWアクセスでSTREAMまたはDYNAMICバッファデータを使用することを意味します。これは、パフォーマンスへの大きな影響を回避するのに十分なはずです。

于 2012-05-09T01:56:21.550 に答える
2

これに対する唯一の正解はありません。ここにあなたの決心をするのに役立つかもしれないいくつかのことがあります：

  1. バスを通過するデータの量が問題になるほど大きいと確信していますか? 計算を行って、1 秒あたりのデータ量とターゲット ハードウェアで利用可能なデータ量を確認することをお勧めします。
  2. アプリケーションは CPU バウンドまたは GPU バウンドの可能性がありますか? すでに GPU にバインドされている場合は、それ以上ロードしても意味がありません。
  3. パーティクル システムは、CPU に簡単に実装でき、どのハードウェアでも実行できます。自明でない粒子システムをサポートする GPU 実装はより複雑になり、必要な機能をサポートするハードウェアに限定されます (例: ストリーム出力とそれにアクセスできる API)。
  4. 混合アプローチを検討してください。粒子システムを、GPU に実装された低複雑性で高帯域幅の粒子システムと、CPU に実装された高複雑性で低帯域幅のシステムに分割できますか?

そうは言っても、CPU の実装から始めて、必要かつ実行可能であることが判明した場合は、作業の一部を GPU に移すと思います。

于 2012-05-09T01:43:38.123 に答える