私が理解していることから、推奨されるワーク グループ サイズは、コンピューティング デバイスの SIMD 幅にほぼ依存します (NVidia の場合、これはワープ サイズであり、AMD では用語は Wavefront です)。
論理的には、好ましいワークグループのサイズは、カーネルに依存するのではなく、デバイスに依存すると想定することになります。ただし、このプロパティを照会するには、CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE を使用して特定のカーネルに対して相対的に行う必要があります。基になるハードウェア デバイスの SIMD 幅の倍数ではない値を選択すると、ハードウェアが完全にロードされず、パフォーマンスが低下します。また、どのカーネルが実行されているかに関係なく選択する必要があります。
私の質問は、なぜそうではないのですか？確かに、この設計上の決定は完全に恣意的なものではありませんでした。根本的な実装上の制限はありますか?または、このプロパティが実際にカーネル プロパティであるべき場合はありますか?
__attribute__OpenCL 1.2 仕様のセクション 6.7.2 を読んだ後、キーワードを使用して必須または推奨のワークサイズ ヒントを指定するコンパイラ属性をカーネルが提供できることがわかりました。このプロパティは、優先ワーク グループ サイズの倍数がカーネル プロパティとデバイス プロパティである場合にのみ、ホストに渡すことができます。
理論的に最適なワークグループ サイズの選択は、デバイス固有のプロパティである可能性がありますが、特定のカーネルに対して必ずしも最適に機能するとは限りません。たとえば、最適に機能するのは、の倍数2*CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLEまたはすべてを組み合わせたものです。
論理的にあなたが言っていることは正しいです。ここでは、SIMD によって達成されるデータの並列処理のみを考慮しています。SIMD の値は、char 用と double 用の別のデータ型でも変化します。また、すべてのワークアイテムは、ローカル メモリを介してワーク グループ内のメモリ リソースを共有します。ローカル メモリは、基盤となるハードウェアの SIMD 機能の倍数である必要はなく、基盤となるハードウェアには複数のローカル メモリがあります。
GPU には、計算する必要があるタスク/ジョブのキューを持つ多くのプロセッサがあります。
RAM アクセスによってブロックされているために実行を待機しているタスク、またはジェット実行されていないタスクを「飛行中」と呼びます。
あなたの質問に答えるには、処理中のタスクの数は、グラフィックス カードの RAM へのアクセスによって生じる待機遅延を補うのに十分な数でなければなりません。
参考文献： スレッド1