OpenCL を学習するのに比較的短い時間でしたが、アプリケーションが原因でオペレーティング システムの UI の応答が大幅に低下するのを頻繁に目にします (たとえば、ウィンドウがドラッグに応答するのに数秒かかります)。この問題は、NVidia GPU を搭載した Windows Vista と Mac OS X で発生しました。
ディスプレイと同じ GPU で OpenCL を使用する場合、アプリケーションがこのように UI の応答性を大幅に低下させないようにするにはどうすればよいですか? また、アプリケーション内で不必要にパフォーマンスを低下させることなく、これを行うことはできますか? (つまり、ユーザーが UI を集中的に使用するタスクを実行していない場合、アプリケーションの実行速度が現在より遅くなるとは思わないでしょう。)
回答はプラットフォーム固有のものであることを理解しています (プラットフォームには OS/GPU/ドライバーの組み合わせが含まれます)。
David Gohara博士のOpenCLチュートリアルエピソード6（43:49から開始）で説明されているように、現時点ではグラフィックカードをプリエンプティブにスケジュールすることはできません。その結果、集中的なOpenCLカーネルとUI（または他のGPUを使用する操作）の両方に同じグラフィックカードを使用すると、不格好またはフリーズの視覚的な外観になります。グラフィックカードがプリエンプティブにスケジュールされたマルチタスクを取得するまで（もしあれば）、1枚のグラフィックカードだけであなたが望むことを正確に行う方法はありません。これがプラットフォーム固有の問題であるとはまったく思わない。
ただし、この問題は、問題を分割することで解決できる場合があります。利用可能な単一のGPUの相対速度を考えると（適切なセットアップを見つけるためにテストを行う必要があります）、OpenCLの問題を分割して、入力データのさまざまな部分でカーネルを複数回実行し、後で出力データを結合しますカーネルのすべてのセットが完了したとき。（特定のGPUで）実行に100ミリ秒未満かかるカーネルセットを作成することをお勧めします。これにより、ラグが目立たなくても、それほど煩わしくなりません（このペーパーによると、100ミリ秒の数値は適切な「経験則」です。 ）。
あなたのプログラムがコマンドラインアプリケーションであるというあなたのコメントに基づいて、多くのOpenCLデモがそうであるように、あなたのアプリケーションはリアルタイム出力で継続的に実行されるアプリケーションであるのに対して、いつでも一度だけ実行されると思います。リアルタイムのパフォーマンスは本質的に期待されていないため、上記の答えは非連続的なアプリケーションに対してのみ満足のいくものです。ただし、アプリケーションが継続的であると想定される場合、現在利用可能な唯一の解決策は、UIにのみ使用される2番目のより単純なグラフィックカードを追加することです。