これをタイトルの質問の完全な形式と考えてください: OpenCL は、将来 (他のデバイス プログラミングの中でも) 本格的な GPU プログラミングの共通標準になる可能性があるため、OpenGL 用にプログラミングするときは、将来的に保証される方法で、すべての GPU を使用しない理由はありません。 OpenCLでの操作?そうすれば、プログラム上の制限なしに GLSL の利点を得ることができます。
4 に答える
GLSL はOpenGLシェーディング言語です。もともとは、グラフィックス パイプラインを制御するためのものです。
一方、OpenCL はOpen Computing Languageです。グラフィックスではなく、計算を制御します。
2 つのテクノロジは、異なる能力と機能を対象としています。
そうは言っても、今後は、計算目的で GLSL を使用する理由はほとんどないかもしれません。ただし、現在のところ、OpenCL よりも多くのベンダーが GLSL を完全にサポートしているため、少なくとも現時点では、GLSL はコアの目的ではないため制限されていますが、計算目的には依然として有用です。
将来、OpenCL は GLSL を置き換えることができるかもしれません。それまでの間、少なくとも最も重要な (NVidia/ATI) 実装では、OpenGL 相互運用性にまだいくつかの問題があります。
ただし、 OpenCL がOpenGL を完全に置き換えるわけではありません。ラスター グラフィックに関しては、OpenGL はさらに多くのことを行います。OpenCL の唯一のラスター グラフィック プリミティブはテクスチャ/イメージであり、グラフィックをまったくレンダリングできません。
GLSL は「シェーディング言語」です。これは 3D レンダリングに使用され、その目的に特に役立つ特別なデータ型を持っています (例: 長さ 4 のベクトルとランク 4x4 の行列)。頂点シェーダーとフラグメント シェーダーは、レンダリング パイプライン内の適切に定義された場所にあり、このパイプラインを流れるデータで自動的にトリガーされます。シェーダーは、3D パイプラインの変換行列と投影行列にも直接アクセスできます。
OpenCL は「計算言語」です。これは、3D レンダリングで見られる計算タスク用に特別に設計されたものではなく、むしろ C のサブセットです。OpenCL には GLSL のベクトルと行列に似たデータ型 (float4、float16) がありますが、使用するのはあまり便利ではありません。また、グラフィックス コンテキストがなく (長所にも短所にもなり得ます)、OpenCL カーネルが 3D レンダリング パイプライン内に存在しません。
3D レンダリング パイプラインにプラグインされ、レンダリング パイプラインによってトリガーされる計算モジュールが必要な場合は、GLSL を使用します。3D レンダリング パイプライン外の GPU で一般的な計算が必要な場合は、OpenCL を使用します。
これは、3D グラフィックスのレンダリングに OpenCL を使用できないという意味ではありません。できる。実際、OpenCL だけで独自のパイプラインを実装してから、描画をフレームバッファにコピーできます。しかし、3D グラフィックスを描画したいだけなら、SGI、Nvidia、Intel、AMD のエンジニアによるすべての作業を複製するのは、おそらく面倒なことではありません。次に、GLSL を使用するだけで、すぐに使用できる完全にパフォーマンスの高い OpenGL パイプラインにシェーダーをプラグインする方が簡単です。オープンソースの OpenGL 実装である Mesa を作成するのは大きな仕事だったと考えてください。
@dietr: ここでエコさせてください!CL/GL の相互運用性は、特に多数のオブジェクト バッファ (たとえば、100 を超える) を処理する場合に、全体的なパフォーマンスにかなりの悪影響を与える可能性があります。コンテキスト変更のオーバーヘッドと、バッファーの構造体またはバッファーへのポインターのサポートの欠如により、アプリが強制終了されてしまうため、opencl コードを置き換えるためにジオメトリ シェーダーの使用を真剣に検討しています。だまされてはいけません。opengl 全体を opencl に完全に置き換えるには、再コーディング プロセス全体が必要になります。その上、ここの人々によってよく言われているように、opengl はパイプライン計算だけではありません。CL/GL iterop を使用する場合は、可能であれば頂点/ジオメトリ シェーダーのコードを書き直してみてください。