OpenCL 计算单元和 GPU 处理单元不匹配答案

【问题标题】：OpenCL Compute units and GPU Processing units mismatchOpenCL 计算单元和 GPU 处理单元不匹配
【发布时间】：2020-09-13 08:48:19
【问题描述】：

我对计算单元有点困惑。我有一个 nvidia gtx 1650Ti 显卡。当我询问 max_compute_units 时，它返回 16 个单位，而 max_work_group_size 为 1024。但是当我执行内核时：

int i = get_global_id (0);
result [i] = get_local_id (0);

我得到重复的本地 id 范围从 0 到 255。这与显卡返回的 max_compute_units 有什么关系？这是 max_compute_units 值中的错误，并且 gpu 实际上具有比它指示的更多的计算单元吗？还是 OpenCl get_local_id 有自己的分配逻辑，不依赖于硬件？谢谢！

【问题讨论】：

标签： opencl pyopencl

【解决方案1】：

OpenCL 计算单元是指 Nvidia GPU 上的流式多处理器 (SM) 或 AMD GPU 上的计算单元 (CU)。每个 SM 包含 128 个 CUDA 内核（Pascal 和更早版本）或 64 个 CUDA 内核（Turing/Volta）。对于 AMD，每个 CU 包含 64 个流式多处理器。这是指硬件。 SM/CU 越多，GPU 越快（在相同的微架构内）。

工作组大小/本地 ID 是指您如何将软件中的线程分组为所谓的线程块。例如，线程块对于矩阵乘法很有用，因为在线程块中，线程之间的通信可以通过共享内存进行。线程块可以有不同的大小（一种优化参数，32、64、128、256、512 或 1024 (max_work_group_size)）。根据您的 GPU，一些中间值也可能有效。在硬件上（至少对于 Nvidia 而言），线程块在 SM 上作为所谓的 warp（32 个线程组）执行。对于图灵，一个 SM 可以同时计算 2 个扭曲。如果选择 16 的线程块大小，那么每个 warp 只计算 16 个线程，其他 16 个线程空闲，所以你只能得到一半的性能。

在您的示例中，本地 ID（这是线程块中的索引）介于 0 和 255 之间，您的线程块大小为 256。您将内核调用中的线程块大小定义为“本地范围”。 max_work_group_size 与 max_compute_units 没有任何关系；两者都是硬件/驱动程序限制。

【讨论】：

非常感谢您提供如此详细的解释！据我了解，我的 GPU 能够同时处理 16 个工作组（max_compute_units），每个组在 3 个维度（max_work_group_size）中总共可以支持多达 1024 个线程。现在一切都变得清晰了！所以我应该尝试为每个工作组（local range=max_work_group_size）使用所有可用线程，并减少工作组的总数以获得最佳性能，对吧？
虽然一切看起来都比较复杂。据说工作组的数量和组内的线程数量之间需要平衡。由于最重要的因素是内存访问，这比计算要长得多。有必要保持这样一个工作组及其线程的比例，以便第一个处理的组接收来自内存的响应，而队列中的最后一个正在处理。据我了解，这种方法称为延迟隐藏。如果我错了，请纠正我。但是如何找到合适的比例呢？有什么公式吗？谢谢！
内存访问是否真的是瓶颈取决于您的确切算法。对于 1650 Ti，如果您的算法从/向内存传输的每个字节执行少于 16 个浮点运算，则内存带宽是瓶颈，否则计算性能。请参阅 Wikipedia 上的屋顶线模型。延迟隐藏受工作组大小选择的影响较小，但更多地受您的内存访问模式（数组结构与结构数组）的影响。您应该选择 AoS 来获得内存合并，只有这样您才能获得峰值内存带宽并且延迟被隐藏。
大型工作组并不总是有益的。在大型工作组中，您可以更好地使用共享内存，但是如果存在 if-else 分支并且一些线程具有 if-branch 和一些 else-branch，则工作组内的所有线程都必须执行这两个分支并丢弃结果的另一个分支。如果工作组更小，则更有可能在一个工作组中所有线程只执行一个分支（然后根本不需要计算另一个分支）并且您可以获得更好的性能。尝试不同的大小，看看哪个在您的应用程序中具有最佳性能。