OpenCL は GPU のメモリ アーキテクチャを制御し、より優れた最適化を可能にすることは知っていますが、これを別にすれば、ベクトル演算 (加算、乗算、反転など) に Compute Shader を使用できますか?
ベストアンサー1
他の OpenGL シェーダー タイプとは対照的に、コンピュート シェーダーはコンピューター グラフィックスとは直接関係がなく、CUDA や OpenCL と同様に、基盤となるハードウェアのより直接的な抽象化を提供します。カスタマイズ可能なワーク グループ サイズ、共有メモリ、グループ内同期など、CUDA や OpenCL でよく知られているすべての機能を提供します。
基本的に主な違いは次のとおりです。
- OpenCL C の代わりに GLSL を使用します。これらのプログラミング言語の間にはそれほど大きな違いはありませんが、高度なテクスチャ タイプ (キューブ マップ配列など)、高度なフィルタリング (ミップマッピングなど。ミップ レベルはおそらく自分で計算する必要があります)、4x4 マトリックスや幾何学関数などの便利な機能など、OpenCL では利用できないグラフィックス関連の GLSL 機能をすべて使用できます。
- これは、他の GLSL シェーダーと同様に OpenGL シェーダー プログラムです。つまり、OpenGL データ (バッファー、テクスチャ、画像など) へのアクセスは簡単ですが、OpenGL と OpenCL/CUDA 間のインターフェイスは面倒で、ユーザー側で手動で同期を行う必要がある可能性があります。同様に、既存の OpenGL ワークフローへの統合も簡単ですが、OpenCL の設定はそれ自体が 1 冊の本であり、既存のグラフィックス パイプラインへの統合は言うまでもありません。
つまり、コンピュート シェーダーは、既存の OpenGL アプリケーション内での使用を目的としていますが、他のシェーダー ステージのグラフィックス アプローチとは対照的に、通常の (OpenCL/CUDA のような) コンピュート アプローチを GPU プログラミングに採用しています。他のシェーダー ステージのグラフィックス アプローチには、OpenCL/CUDA のようなコンピュート柔軟性がありません (もちろん、他の利点もあります)。そのため、コンピュート タスクを実行することは、一般的なコンピューティングを目的としていない他のシェーダー ステージに押し込んだり、同期する必要がある追加のコンピューティング フレームワークを導入したりするよりも、柔軟で直接的かつ簡単です。
コンピュート シェーダーは、OpenCL で実現可能なほぼすべてのことを、同じ柔軟性とハードウェア リソースの制御、および同じプログラミング アプローチで実行できるはずです。したがって、実行したいタスクに対して GPU に適した優れたアルゴリズム (CUDA または OpenCL で適切に機能する) がある場合は、コンピュート シェーダーでも実行できます。ただし、コンピュート シェーダーのためだけに OpenGL (そもそもリアルタイム コンピューター グラフィックスのフレームワークであり、今後もそうあり続けるでしょう) を使用するのは、あまり意味がありません。このためには、OpenCL または CUDA を使用できます。コンピュート シェーダーの真の強みは、グラフィックスとコンピューティング機能を混在させたときに発揮されます。