6

2 つの部分からなる質問:

私は gpgpu を実験する手段としてライフ ゲームを使用する学校のプロジェクトに取り組んでいます。私はリアルタイムの視覚化に OpenCL と OpenGL を使用しています。目標は、これを可能な限り大きく高速にすることです。プロファイリングを行ったところ、フレーム時間は CL による GL バッファーの取得と解放によって支配されており、時間コストはバッファーの実際のサイズに正比例していることがわかりました。

1) これは正常ですか? なぜこれが必要なのですか？私の理解では、バッファはデバイス メモリから離れることはなく、CL の取得/解放はミューテックスのように機能します。OpenCL は各バイトを個別にロック/ロック解除しますか?

これを回避するために、24 ビット RGBA カラー モード (私が理解している OpenGL の優先カラー モード?) から 8 ビット RGB カラーに縮小しました。これにより大幅なスピードアップが実現しましたが、カーネルを調整した後、転送時間が再び支配的になりました。

転送時間を完全になくす方法についてのアイデアがない場合 (プロジェクトの元の範囲を超える OpenCL から GLSL へのカーネルの移植を除いて)、私の最善の策はビットマップ (私が現在使用している8ビットのピックスマップとは対照的に）、そのビットマップをカラーインデックスとともに使用して、クワッドをテクスチャリングします。

2) ビットマップを使用してクワッドを直接テクスチャリングできますか? glBitmap を使用して補助バッファーに描画し、このバッファーを使用してクワッドをテクスチャリングすることを検討しましたが、利用可能な場合はより直接的なルートを使用することをお勧めします。

4

1 に答える 1

2

CL/GL 相互運用の取得呼び出しと解放呼び出しの背後にある設計意図は、単純に所有権を譲渡することでした。ただし、多くの初期の実装では、これらは CL から GL へ、およびその逆のイメージのコピーを行っていました。

OpenCL 1.1 で同期オブジェクト拡張機能を使用しない限り、リリース前に clFinish し、取得前に glFinish する必要があります。これらの呼び出しを続行する前に、キューに入れられたすべての作業を終了する必要があるため、ここで多くの時間が費やされます。一部のプラットフォームでは、clFinish の代わりに clFlush を使用できます。ベンダーの OpenCL ドキュメントを確認してください。

多かれ少なかれ最近のハードウェアに最新の NVIDIA および AMD ドライバーを使用すると、HD ビデオ サイズの画像の取得と解放の呼び出しが非常に迅速に行われます。

于 2012-12-09T19:48:31.503 に答える