据我了解，首选工作组大小大致取决于计算设备的 SIMD 宽度（对于 NVidia，这是 Warp 大小，在 AMD 上是 Wavefront）。
从逻辑上讲，这会导致人们假设首选的工作组大小是设备相关的，而不是内核相关的。但是，要查询此属性，必须使用 CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE 相对于特定内核来完成。选择一个不是底层硬件设备 SIMD 宽度倍数的值不会完全加载硬件，从而导致性能降低，并且应该与正在执行的内核无关。
我的问题是为什么不是这样？当然，这个设计决定并不是完全武断的。是否存在一些底层实现限制，或者是否存在此属性真的应该是内核属性的情况？
从逻辑上讲，您所说的是正确的，这里您只考虑 SIMD 实现的数据并行性，SIMD 的值也会因不同的数据类型而变化，一种用于 char，另一种用于 double 而且您忘记了所有工作项通过本地内存共享工作组中的内存资源。本地内存不一定是底层硬件SIMD能力的倍数，底层硬件有多个本地内存。
在阅读了 OpenCL 1.2 规范的第 6.7.2 节后，我发现允许内核提供编译器属性，这些属性使用__attribute__关键字指定所需或推荐的工作大小提示。仅当首选工作组大小倍数是内核属性与设备属性时，才能将此属性传递给主机。
理论上最好的工作组大小选择可能是特定于设备的属性，但它不一定最适合特定内核，或者根本不适合。例如，最有效的可能是多个2*CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE或所有的东西。
首选的工作组大小倍数 (PWGSM) 是内核，而不是设备属性，以说明矢量化。
假设硬件有 16 个宽 SIMD 单元。那么一个全标量内核的 PWGSM 可能为 16，假设编译器设法进行全自动矢量化；类似地，对于在编译器周围使用 float4s 的内核，仍然能够找到将工作项合并为 4 个组的方法，并推荐 PWGSM 为 4。
In practice the only compilers that do automatic vectorization (that I know of) are Intel's proprietary ICD, and the open source pocl. Everything else always just returns 1 (if on CPU) or the wavefront/warp width (on GPU).
GPU 确实有许多处理器，它们确实有一个应该计算的任务/作业队列。
我们将等待执行的任务称为等待执行的任务，因为它们被 RAM 访问阻塞或未在“飞行中”执行。
要回答您的问题，运行中的任务数量必须足够高，以补偿访问显卡 RAM 所带来的等待延迟。
参考： 线程 1