为什么首选工作组大小是内核属性的多个部分?

时间:2013-04-07 19:41:24

标签: opencl gpgpu

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

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

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

4 个答案:

答案 0 :(得分:1)

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

答案 1 :(得分:1)

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

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

答案 2 :(得分:1)

首选工作组大小倍数(PWGSM)是内核而不是设备属性,用于说明向量化。

让我们说硬件有16个宽的SIMD单元。假设编译器设法进行全自动矢量化,那么完全标量内核的PWGSM可以为16;类似地,对于使用float4s的内核,编译器仍然可以找到合并4个组中的工作项的方法,并推荐一个4的PWGSM。

在实践中唯一进行自动矢量化的编译器(我所知道的)是英特尔的专有ICD和开源pocl。其他所有东西总是只返回1(如果在CPU上)或波前/扭曲宽度(在GPU上)。

答案 3 :(得分:-1)

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

我们调用等待执行的任务,因为它们被RAM访问阻止或者没有“飞行中”喷射执行。

要回答你的问题,飞行任务的数量必须很高,以补偿访问显卡RAM的等待延迟。

参考文献: Thread 1