我真的不了解OpenCL中工作组的目的。
据我所知，他们是一组工作项（据称是硬件线程），它们是并行执行的。
然而，为什么需要更粗略的细分？只有线程网格（而且，事实上，只有一个W-G）不是没有问题吗？
工作组是否应该完全映射到物理核心？例如，据说TESLA c1060卡有240个核心。工作组将如何映射到这个？
另外，据我所知，由于内存栅栏，工作组内的工作项可以同步。工作组可以同步还是甚至需要？他们是通过共享内存互相交谈，还是只针对工作项目（这个不确定）？
答案 0 :(得分：24)
我认为部分混乱归结为术语。 GPU人们经常称之为核心，并不是真的，而且人们经常称之为线程的GPU只是在某种意义上。
<强>芯 GPU营销术语中的核心可能指的是类似CPU核心的东西，或者它可能指的是SIMD单元的单个通道 - 实际上单核x86 CPU将是这种更简单类型的四个核心。这就是GPU核心数量如此之高的原因。这不是一个公平的比较，你必须除以16,32或类似的数字，以获得更直接可比的核心数。
<强>工作-项 OpenCL中的每个工作项都是一个关于其控制流和内存模型的线程。硬件可以在一个线程上运行多个工作项，您可以通过设想在SSE向量的单独通道上运行的四个OpenCL工作项来轻松地对此进行描绘。它只是编译器技巧实现了这一点，并且在GPU上它往往是编译器技巧和硬件辅助的混合。 OpenCL 2.0实际上通过子组公开了这个底层硬件线程概念，因此需要处理另一层次的层次结构。
<强>工作的基团 每个工作组都包含一组工作项，必须能够在存在障碍的情况下取得进展。实际上，这意味着它是一个集合，其所有状态都能够同时存在，这样当遇到同步原语时，它们之间的切换开销很小，并且可以保证切换是可能的。
工作组必须映射到单个计算单元，这实际上意味着整个工作组适合CPU人们称之为核心的单个实体--CUDA将其称为多处理器（取决于代），AMD计算单元和其他人有不同的名称。这种执行的位置导致更高效的同步，但它也意味着该组工作项可以访问本地构造的内存单元。他们需要经常进行通信，或者不能使用障碍，为了使这种通信高效，可能存在本地缓存（类似于CPU L1）或暂存存储器（OpenCL中的本地存储器）。
只要使用障碍，工作组就可以在内部，工作项之间，使用本地内存或使用全局内存进行同步。工作组不能彼此同步，并且标准不保证工作组相对于彼此的前进进度，这使得构建便携式锁定和同步原语实际上是不可能的。
很多这是由于历史而不是设计。 GPU硬件长期以来被设计用于构造矢量线程并以最佳方式处理三角形的方式将它们分配给执行单元。 OpenCL不会推断硬件对其他东西有用，但不能将它推广得太多以至于实现效率低下。
答案 1 :(得分：4)
已经有很多好的答案，因为进一步理解OpenCL this paper的术语实际上很好地描述了所有的概念。
答案 2 :(得分：3)
使用工作组可以对内核编译器进行更多优化。这是因为数据不在工作组之间传输。根据使用的OpenCL设备，可能存在可用于局部变量的高速缓存，以实现更快的数据访问。如果只有一个工作组，则局部变量将与全局变量相同，这将导致数据访问速度变慢。
此外，通常OpenCL设备使用单指令多数据（SIMD）扩展来实现良好的并行性。一个工作组可以与SIMD扩展并行运行。
Should a Work-Group exactly map to a physical core ?
我认为，只有找到最快的工作组大小的方法是尝试不同的工作组大小。也可以使用clGetKernelWorkGroupInfo从设备查询CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE。最快的大小应该是其中的一倍。
Can work-groups synchronize or is that even needed ?
工作组cannot be synchronized。这样，它们之间就没有数据依赖关系，如果认为它们是运行它们的最快方式，它们也可以按顺序运行。为了实现相同的结果，比工作组之间的同步，内核需要拆分成多个内核。可以使用缓冲区在内核之间传输变量。
答案 3 :(得分：3)
工作组的一个好处是它们可以使用共享本地内存作为程序员定义的缓存。从全局内存读取的值可以存储在共享工作组本地内存中，然后由工作组中的任何工作项快速访问。一个很好的例子就是生命游戏：每个细胞依赖于自身和周围的细胞。如果每个工作项都读取此信息，则您有9次全局内存读取。通过使用工作组和共享本地内存，您可以接近1x全局内存读取（只有方法，因为边缘有冗余读取）。