OpenCL显示2个单位，而我的GPU设备实际上有很多核心 - 为什么？

Question

我正在尝试使用OpenCL运行我的程序。

我在日志中看到了以下信息：

OpenCL device #0: GPU NVIDIA Corporation GeForce GT 730 with OpenCL 1.2 (2 units, 901 MHz, 4096 Mb, version 391.35)
OpenCL device #1: GPU NVIDIA Corporation GeForce GT 730 with OpenCL 1.2 (2 units, 901 MHz, 4096 Mb, version 391.35)
OpenCL device #2: CPU Intel(R) Corporation Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz with OpenCL 2.1 (8 units, 4000 MHz, 16300 Mb, version 7.0.0.2567)

我从上述信息中猜测，我的GPU设备每个 2个单位作为工作项。

在使用CudaZ实用程序检查GPU设备的规格后，我发现在[PCI_LOC = 0：1：0]中为GPU设备报告了 384核心。

见图片：

clinfo显示以下内容：gist of clinfo

我的问题是，当我每个拥有384个核心时，为什么会显示2个单位？其次，当我有很多内核时，openCL如何分配任务，它是在每个核心相同的进程和相同的数据上，还是不同的核心与不同的数据？

Answer 1

  

我的问题 ，当我每个拥有384个核心时，那么为什么会显示2个单位？

易，
与任何通用CPU CISC / RISC计算设备相比，GPU计算设备与其他硅硬连线架构不同。

为什么的原因在这里非常重要。

GPU设备使用 S treaming M 多处理器和 X 执行单元（ SMX 单元）在一些硬件检测工具中。

虽然S M X缩写中的字母 M 强调，但是可以在SMX单元上加载多个执行，但是，所有这些情况实际上都会执行（确定，只有以超出本主题范围的方式指示覆盖/跨越每个SMX存在的SM核心时，才能使用相同的计算指令 - 这是他们可以操作的唯一方法 - 它被称为 SIMD 类型的有限并行范围，仅在SMX的周边可实现（共同本地），其中 s ingle- i nstruction- m ultiple- d ata可以在当前的SIMD（WARP-wide | half-WARP-wide）-scheduler功能中执行。

列出上面列出的384个核心意味着硬件限制，超出这个限制，这种共同本地协调的SIMD类型的有限范围并行性不能增长，并且所有尝试进入这个方向将导致纯粹的 [SERIAL] GPU作业的内部调度（是的，即一个接一个）。

理解这些基础知识是基本的，因为没有这些架构特征，人们可能会期望一种行为，实际上根本不可能在任何类型的GPGPU系统中进行编排，具有 {{1}的正式形状} 自主，异步distributed-system节点星的组合。

从CPU主机加载到GPU上的任何GPU内核都将映射到一组非空的SMX单元，其中指定数量的核心（另一个更精细的粒子几何计算资源是应用，再次超出本文的范围）加载SIMD指令流，而不是违反GPU设备限制：

[ 1-CPU-host : N-GPU-device(s) ]

所以，

• 如果 1-SM-core 在内部被指示执行某个GPU任务单元（GPU作业），那么这一个SM-core将获取一个GPU-RISC指令接下来（为了简化而忽略任何可能的ILP）并一次执行一个，逐步执行所述GPU作业的SIMD指令流。存在于同一SMX单元上的所有其他SM内核通常在此期间不执行任何操作，直到此GPU作业完成并且内部GPU进程管理系统决定为此SMX映射其他一些工作。

• 如果 2-SM-cores 被指示执行一些GPU工作，那么这对SM内核将获取一个（并且非常相同 ）GPU-RISC指令接着另一个（为了简单起见忽略任何可能的ILP）并且两者一次执行一个，逐步执行所述GPU作业的SIMD指令流。在这种情况下，如果一个SM核进入一个条件，其中 ... +---------------------------------------------------------------------------------------- Max work items dimensions: 3 // 3D-geometry grids possible Max work items[0]: 1024 // 1st dimension max. Max work items[1]: 1024 Max work items[2]: 64 // theoretical max. 1024 x 1024 x 64 BUT... +---------------------------------------------------------------------------------------- Max work group size: 1024 // actual max. "geometry"-size +---------------------------------------------------------------------------------------- ... -ed或类似分支的执行流程使一个SM核进入另一个代码执行流动路径比另一个， SIMD - 并行主义进入不同的场景，其中一个SM核心获得下一个SIMD指令，属于它的代码执行路径，而另一个一个人什么都不做（得到一个GPU_NOP（s）），直到第一个完成整个工作（或被强制停止在某个同步障碍中落入一个不可屏蔽的延迟等待状态，等待一段数据被取出来自＆＃34; far＆＃34;（慢）非本地内存位置，再次，细节超出了这篇文章的范围） - 只有在任何一个发生之后，发散路径，到目前为止只是GPU_NOP-ed SM-core可以接收任何下一个SIMD指令，属于其（发散的）代码执行路径以向前移动。存在于同一SMX单元上的所有其他SM内核通常在此期间不执行任何操作，直到此GPU作业完成并且内部GPU进程管理系统决定为此SMX映射其他一些工作。

• 如果 16-SM-cores 被指示通过特定于任务的几何＆＃34;执行某些GPU作业，只需这个＆＃34; herd＆＃34 ; SM内核将逐个获取一个（以及非常相同）GPU-RISC指令（为了简单起见，忽略任何可能的ILP）并且 all 执行一个一段时间，逐步完成所述GPU作业的SIMD指令流。 ＆＃34;牧群内的任何分歧＆＃34;减少SIMD效应和if - 被阻止的核心仍在等待＆＃34;牧群的主要部分＆＃34;完成这项工作（与此时正好相同）。

无论如何，所有其他SM核心，没有按任务特定的几何形状映射＃34;在相应的GPU设备上＃39; SMX单元通常不会做任何有用的事情 - 因此了解适当的任务特定的几何形状的硬件细节的重要性。确实非常重要，分析可能有助于确定任何此类GPU任务星座的峰值性能（差异可能在几个数量级范围内 - 从最佳到共同到更差 - 在所有可能的任务特定＆＃34;几何＆＃34;设置中）。

  

其次， 当我有多个核心， openCL如何分配任务时，是否在每个核心相同的进程上相同的数据还是不同的核心与不同的数据？

正如上面简要解释的那样 - GPU_NOP 类型的设备硅架构不允许任何SMX SM内核执行除了完全相同的SIMD指令之外的任何其他内容整个＆＃34;牧群＆＃34; -of-SM-核心，由任务映射 - ＆＃34;几何＆＃34;在SMX单元上（不计算SIMD（s）做＆＃34; 别的东西＆＃34;因为它只是浪费CPU：GPU系统时间。 / p>

所以，是， ＆＃34; ..在每个核心相同过程..＆＃34; （最好，如果在 GPU_NOP 之后，其内部代码执行路径中从不发散 if 或任何其他类型的代码执行路径分支），因此如果基于数据驱动值的算法导致不同的内部状态，则每个核心可能具有不同的线程局部状态，处理可能的基础不同（如上面的 while 驱动的不同代码执行路径所示）。有关SM本地寄存器，SM本地缓存，受限共享内存使用（和延迟成本），GPU设备全局内存使用（以及延迟成本和缓存行长度以及关联性的最佳合并访问模式的关联性）的更多详细信息屏蔽选项 - 许多与硬件相关的+编程生态系统详细信息涉及数千页的硬件+软件特定文档，并且远远超出了为简化起见而简化帖子的范围）

  

相同数据 或与不同数据的核心不同？

这是最后但并非最不重要的困境 - 任何参数化良好的GPU内核激活也可能会在GPU内核之外传递一些外部世界数据，这可能使SMX线程本地数据与SM-core不同到SM核心。执行此操作的映射实践和最佳性能主要是特定于设备的（{SMX | SM-registers | GPU_GDDR gloMEM：shaMEM：constMEM | GPU SMX-本地缓存 - 层次结构} - 详细信息和容量

if

主要是设备与设备的不同，每个高性能代码项目主要可以分析其各自的GPU设备任务 - ＆＃34;实际部署设备的几何和资源使用图组合。什么可以在一个GPU设备/ GPU驱动器堆栈上更快地工作，不需要在另一个上工作（或者在GPU驱动程序+外部编程生态系统更新/升级之后），只是现实基准测试将告诉（因为理论很容易打印，但很难执行，因为许多特定于设备和工作负载的限制将适用于实际部署）。