2

据我了解,首选工作组大小大致取决于计算设备的 SIMD 宽度(对于 NVidia,这是 Warp 大小,在 AMD 上是 Wavefront)。

从逻辑上讲,这会导致人们假设首选的工作组大小是设备相关的,而不是内核相关的。但是,要查询此属性,必须使用 CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE 相对于特定内核来完成。选择一个不是底层硬件设备 SIMD 宽度倍数的值不会完全加载硬件,从而导致性能降低,并且应该与正在执行的内核无关。

我的问题是为什么不是这样?当然,这个设计决定并不是完全武断的。是否存在一些底层实现限制,或者是否存在此属性真的应该是内核属性的情况?

4

4 回答 4

1

从逻辑上讲,您所说的是正确的,这里您只考虑 SIMD 实现的数据并行性,SIMD 的值也会因不同的数据类型而变化,一种用于 char,另一种用于 double 而且您忘记了所有工作项通过本地内存共享工作组中的内存资源。本地内存不一定是底层硬件SIMD能力的倍数,底层硬件有多个本地内存。

于 2013-04-09T10:26:36.623 回答
1

在阅读了 OpenCL 1.2 规范的第 6.7.2 节后,我发现允许内核提供编译器属性,这些属性使用__attribute__关键字指定所需或推荐的工作大小提示。仅当首选工作组大小倍数是内核属性与设备属性时,才能将此属性传递给主机。

理论上最好的工作组大小选择可能是特定于设备的属性,但它不一定最适合特定内核,或者根本不适合。例如,最有效的可能是多个2*CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE或所有的东西。

于 2013-04-12T06:39:33.440 回答
1

首选的工作组大小倍数 (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).

于 2015-06-05T07:05:25.777 回答
-2

GPU 确实有许多处理器,它们确实有一个应该计算的任务/作业队列。

我们将等待执行的任务称为等待执行的任务,因为它们被 RAM 访问阻塞或未在“飞行中”执行。

要回答您的问题,运行中的任务数量必须足够高,以补偿访问显卡 RAM 所带来的等待延迟。

参考: 线程 1

于 2013-04-08T10:27:16.560 回答