OpenCLパイプラインの一部として、何百もの半透明の円を描く必要があります。簡単なレンダリングの場合：OpenCLはOpenGLより高速ですか？
現在、私はOpenCLキューでclFinishとglFinishを使って（移植性のために）同期されたOpenGL（アルファブレンド付き）を使用しています。
OpenCLでこのレンダリングタスクを実行する方が早いでしょうか？ （パイプラインの残りの部分は既にOpenCLに入っていると仮定し、OpenCL互換のGPUがない場合はCPU上で動作する可能性があります）。
円の場合、ラスタライザを簡単なテスト機能で置き換えるのは簡単です。ブレンド機能では、フラグメントごとにデスティネーションテクスチャからのシングルリードが必要です。したがって、素朴なOpenCLの実装は理論的に高速です。しかし、おそらくOpenGLは重複しない三角形を並行してレンダリングできます（これはOpenCLで実装するのが難しいでしょう）。
OpenCLベースの処理は高速ですが、というのは、CL/GL interopを扱う必要がないためです。 glFinish/clFinishをすべてに実行しなければならないという事実は、ボトルネックです。
これは、固定機能対シェーダハードウェアとは関係ありません。それはすべての同期を取り除くことについてです。
これは、が間違っていることを意味するものではありません。これらのことをOpenCLを使用して表現する方法は間違っています。
あなたがしたいのは、ではなく、1つの計算操作でメモリに色を書き込んだり、別の計算opでブレンドしてメモリに書き戻したりすることです。そういうわけで、狂気がある。
代わりに行うべきことは、効果的に内部的にタイルベースのレンダラーを構築することです。各ワークグループは、ピクセル数を表します（パフォーマンスの最適なカウントを決定するための実験）。各呼び出しは1つのピクセルで動作します。彼らはピクセル位置を使用し、ピクセルが円内にあるかどうか（そしてどれが円内にあるか）を計算し、その呼び出しが内部で保持するローカル変数と混合します。したがって、各呼び出しは円のすべてを処理し、最後にそのピクセルのデータを書き出します。
あなたが巧妙になりたい場合、各作業グループには、特定の領域内の少なくとも一部のピクセルに影響することが保証されている円のみが与えられるように、間引きを行うことができます。これは事実上前処理パスであり、おそらくそれほど高価ではないので、CPU上で行うこともできます。
"*残りのパイプラインはすでにOpenCL *にあると仮定します。"残りのパイプラインについて教えてください。 –
私のアプリの処理パイプライン。私はOpenCLでいくつかの画像を計算し、次にこれらの円をレンダリングしてから、OpenCLで再度処理しなければなりません。 –
ラスタライズまたはレイキャスティングを簡単に呼び出すことができます。私は、これらのことのいずれかを実装すると主張する人の多くが、あなたの代わりにそれを行う特別なAPIを与えられた単純なレンダリングを構成しているとは知らない。 –