【发布时间】:2012-04-10 21:04:06
【问题描述】:
OpenCL 标准定义了以下选项来获取有关设备和编译内核的信息:
CL_DEVICE_MAX_COMPUTE_UNITS
CL_DEVICE_MAX_WORK_GROUP_SIZE
CL_KERNEL_WORK_GROUP_SIZE
CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE
给定这些值,我如何计算工作组的最佳大小和工作组的数量?
【问题讨论】:
标签: opencl
OpenCL 标准定义了以下选项来获取有关设备和编译内核的信息:
CL_DEVICE_MAX_COMPUTE_UNITS
CL_DEVICE_MAX_WORK_GROUP_SIZE
CL_KERNEL_WORK_GROUP_SIZE
CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE
给定这些值,我如何计算工作组的最佳大小和工作组的数量?
【问题讨论】:
标签: opencl
您通过实验为您的算法发现这些值。使用分析器获取硬数字。
我喜欢使用 CL_DEVICE_MAX_COMPUTE_UNITS 作为工作组的数量,因为我经常依赖于同步工作项。我通常运行很少分支的内核,因此在每个计算单元中执行的时间相同。
CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE 的某些倍数最适合您的设备。这个倍数实际上取决于您的内存访问模式和您对每个工作项所做的工作类型。当您运行繁重的计算密集型 (ALU) 内核时,请使用 1 作为倍数。如果您受到内存访问的瓶颈,请尝试使用更大的倍数来隐藏内存延迟。使用分析器来确定您的访问时间和 ALU 时间何时最佳。
对于任何设备,ALU 获取的最佳比率是 1:1。这在实践中很少实现,因此您希望保持 ALU/SIMD 组饱和。这意味着 ALU:fetch 应尽可能大于 1。小于 1 意味着您应该尝试更大的工作组大小以更好地隐藏内存延迟。
【讨论】:
CL_DEVICE_MAX_COMPUTE_UNITS 不会给您最佳性能(除非您在工作组之间进行大量同步,但这通常是个坏主意)。我通常会要求文档提供良好的价值,但我从未见过更多的工作组损害性能,所以越多越好。请注意,只有在您没有使用足够的工作组(例如 CL_DEVICE_MAX_COMPUTE_UNITS,因为 CU 通常一次可以维持一个以上的工作组)时,关于选择更高的工作组大小来隐藏内存延迟的部分(至少对于 gpus)才是正确的。
正如 mfa 所说,您必须通过实验来发现这些。 我想补充一点,这取决于您正在计算的内容(特别是作业的大小,即每个工作项的大小),有时一个好的尝试可以是:
也就是说,基本上检查基本情况并弄清楚它如何影响处理管道。
本质上你必须调整它。我经常针对不同的参数执行几次(分析它),然后生成一个曲面图来查看它的行为。
【讨论】: