问OpenCL:工作组概念

EN

我认为，这里的混乱部分归结于术语。GPU人们通常所说的核心，并不是真正的，而GPU人们通常所说的线程只是在某种意义上。

A核心，在GPU营销术语中，可能指类似于CPU核心的东西，也可能指SIMD单元的单车道--实际上，一个单核x86 CPU将是这种更简单类型的四个核心。这就是为什么GPU核心计数会如此之高的原因。这并不是一个公平的比较，你必须除以16，32或一个类似的数字，才能得到一个更直接可比较的核心计数。

工作项 OpenCL中的每个工作项在其控制流和内存模型方面都是一个线程。硬件可以在一个线程上运行多个工作项，您可以很容易地通过想象在SSE向量的单独通道上操作的四个OpenCL工作项来想象这一点。实现这一目标的只是编译器欺骗，而在GPU上，它往往是编译器欺骗和硬件辅助的混合体。实际上，OpenCL 2.0通过子组公开了这个底层硬件线程概念，因此还有另一个层次结构需要处理。

work每个工作组包含一组工作项，必须能够在存在障碍的情况下取得进展。在实践中，这意味着它是一个集合，所有的状态都能够同时存在，因此当遇到同步原语时，在它们之间切换的开销很小，并且可以保证切换是可能的。

工作组必须映射到单个计算单元，这实际上意味着整个工作组适合CPU人们称之为核心的单个实体-- CUDA将其称为多处理器(取决于生成)，AMD则称为计算单元，其他则具有不同的名称。这种执行的局部性导致更有效的同步，但这也意味着工作项集可以访问本地构造的内存单元。它们需要频繁地进行通信，否则就不会使用障碍，为了提高通信效率，可能会有本地缓存(类似于CPU L1)或划痕板存储器(OpenCL中的本地内存)。

只要使用障碍，工作组就可以在内部、工作项之间、使用本地内存或使用全局内存进行同步。工作组不能相互同步，而且标准不能保证工作组相对于彼此的前进进度，这使得构建可移植的锁定和同步原语实际上是不可能的。

这很多都是历史的原因，而不是设计。长期以来，GPU硬件一直被设计用来构造向量线程，并以一种优化处理三角形的方式将它们分配给执行单元。OpenCL没有将硬件概括为对其他事物有用，但没有将其推广到实现效率低下的程度。

为了进一步理解OpenCL 本论文的术语( Jonathan和Kristofer的“OpenCL编程模型简介”)，已经有很多好的答案，实际上对所有的概念都有很好的描述。

工作组的使用为内核编译器提供了更多的优化。这是因为数据不是在工作组之间传输的。根据已使用的OpenCL设备，可能会有缓存可用于局部变量以获得更快的数据访问。如果只有一个工作组，局部变量将与全局变量相同，这将导致较慢的数据访问。

另外，OpenCL设备通常使用单指令多数据扩展来实现良好的并行性。一个工作组可以与SIMD扩展并行运行。

 Should a Work-Group exactly map to a physical core ?

我认为，找到最快的工作组规模的唯一方法，就是尝试不同的工作组大小。还可以使用CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE从设备中查询clGetKernelWorkGroupInfo。最快的尺寸应该是其中的一倍。

 Can work-groups synchronize or is that even needed ?

工作小组不能同步.这样，它们之间就不存在数据依赖关系，如果它们被认为是运行它们的最快方式，它们也可以按顺序运行。为了实现相同的结果，与工作组之间的同步相比，内核需要分裂成多个内核.变量可以在具有缓冲区的内核之间传输。