我开始构建我的第一个严肃的 OpenCL 程序，我想确保我了解我的 AMD R9 290x 是如何设置的。（GCN 2.0 架构）。所以我只说我理解的，希望有人能告诉我我是对还是错？
在我看来，优化内核的一个主要问题是内存受限的性能。我真的不想在这里做“过早的”优化，但似乎至少考虑内存对于一般的 OpenCL 代码非常重要。（请参阅使用 GPU 进行排序：调查（Dmitri I. Arkhipov + 其他人））
根据AMD 的优化指南，每个向量单元每 4 个时钟可以运行 64 个工作项，每个工作项可以访问 256 个 32 位 vGPR。实际上，__private 数据（尝试）存储在 vGPR 中。
这导致了 1024 个用于 OpenCL 内核的“简单”访问寄存器。
看起来 LDS（又名 __local）可以用作 OpenCL 内核的高效存储，但它们的主要设计似乎是在工作组之间传递数据。由于计算单元的 64kb 在 4 个向量单元之间共享（理想情况下，每个单元至少有 64 个工作项的 1 个波前正在执行），最多可以为每个工作项分配 256 字节的 LDS 空间让系统尽可能“广泛”地运行。
因此，通过一些谨慎的 __local 和 __private 变量分配，每个工作项似乎有 1280 个“快速访问”字节可用。我猜 L1 缓存再授予 16kb（每个工作项只有 64 字节），但这需要一些小心的使用。此外，一级缓存还包含代码/指令，不能全部用于数据。“__constant”空间似乎是有效的 L1 空间，如果波前同步到相同的索引，可能会发生一些“多路复用”魔法。
上述计算均未考虑每个矢量单位的理论 10 波前（似乎共享 vGPR）。如果 R9 290x 实际上有 40 个波前同时执行，它们将仅使用 100 字节（每个工作项 25 个 vGPR）的快速存取存储器。
那么......这是对每个工作项在 R9 290x 等 GCN 设备中获得多少“快速”内存的正确理解吗？如果我们将 vGPR、L1 和 LDS 空间视为 R9 290x 可以使用的“快速”存储空间的总和，那么我们只考虑 1024 (vGPR) + 64 (L1) + 256 (LDS) 空间来工作和。
我确实意识到内核可以访问全局内存（在典型的 R9 290x 上约为 4GB，每个工作项大约为 1MB）。由于 GPU 上的全局内存仍然是高度并行化的 GDDR5 内存，我预计它会相当快，但它仍然比 L1 / vGPRs / LDS 空间慢一个数量级。因此，我希望最佳程序在不需要时尽量避免使用全局 RAM。