【问题标题】:How many tasks can be executed simultaneously on GPU device?GPU 设备上可以同时执行多少个任务?
【发布时间】:2012-06-03 17:03:15
【问题描述】:

我正在使用 OpenCL 并拥有 ATI 4850 卡。它有:

  • CL_DEVICE_MAX_COMPUTE_UNITS:10
  • CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS:3
  • CL_DEVICE_MAX_WORK_GROUP_SIZE:256
  • CL_DEVICE_MAX_WORK_ITEM_SIZES:(256, 256, 256)
  • CL_DEVICE_AVAILABLE:1
  • CL_DEVICE_NAME:ATI RV770

它可以同时执行多少个任务?

是 CL_DEVICE_MAX_COMPUTE_UNITS * CL_DEVICE_MAX_WORK_ITEM_SIZES = 2560 吗?

更具体地说:单核处理器一次只能执行一个任务,双核可以执行2个任务……我的GPU一次可以执行多少个任务?或者换一种说法:我的 GPU 有多少个处理器?

【问题讨论】:

  • 什么意思?一次可以执行多少个内核或GPU上可以运行多少个线程?
  • 可能是内核。我查看了规范,它被称为“处理元素”。所以这个问题可以重新表述:“我的 GPU 有多少处理元素?”
  • 你不能这么轻易地分辨出来。 GPU 具有多个计算单元,每个计算单元同时并行执行多个线程(“warp”或“wavefront”)。对于 nVidia,目前是 32,对于 ATI 64。我不确定是否有与翘曲尺寸相关的 CL 上限。此外,每个计算单元可以有一个未知数量的运行中线程(nVidia 在某些文档中说 1024),当由于某种原因扭曲阻塞时,这些线程是硬件调度的。假设数字相似,这将使您的 GPU 的线程数接近 320,000 个。
  • 除此之外,OpenCL 带来的关于工作项大小和组大小的各种限制,在我看来,这在黑魔法的意义上解释得很多(至少我不能完全了解调整参数的确切作用以及每个参数与实际硬件的关系——这对我来说是一种猜测)。也许那是因为 OpenCL 更加抽象且独立于硬件。或者也许是因为我太愚蠢了,无法理解文档:-)

标签: opencl


【解决方案1】:

RV770 有 10 个 SIMD 核心,每个包含 16 个着色器核心,每个包含 5 个 ALU(VLIW5 架构)。总共 800 个 ALU 可以进行并行计算。我认为没有办法从 OpenCL 中获取所有这些数字。我也不确定您将什么等同于 CPU 内核。也许是着色器核心?你可以阅读VLIW at Wikipedia。这是一个有趣的设计。

如果您说 CPU 内核在任何给定时间仅执行一个“任务”,即使它有多个并行工作的 ALU,那么我猜您可以说 RV770 将处理 160 个任务。但随着不同芯片工作方式的差异,我认为“核心”和“任务”可能变得难以定义。具有超线程的 CPU 甚至可以同时执行两组代码。使用 OpenCL,我认为在任何给定时间执行多个内核是不可能的 - 除非最近的驱动程序更新改变了这一点。

无论如何,我认为以提供最佳性能的方式将您的工作呈现给 GPU 更为重要。不幸的是,除了试验之外,没有办法找到最佳的工作组规模。至少我所知道的不是。一个帮助是,如果驱动程序支持 OpenCL 1.1,您可以查询 CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE 并将您的工作大小设置为它的倍数。否则,选择 64 的倍数可能是一个安全的选择。

【讨论】:

  • 我想你会发现它是 SIMD 核心(单指令,多数据)执行指令获取和解码,然后将这些指令提供给着色器。因此,16 个着色器核心都必须在任何特定时间运行相同的代码。结果是 RV770 只能处理 10 个任务,而不是 160 个。
【解决方案2】:

GPU 工作最终变成波前/扭曲。

将 GPU 用于 UI 和计算实际上是在不知不觉中将它用于许多程序。许多用于 GUI 绘图,以及您正在执行的任何计算内核。快速 OpenCL 客户端是异步的,并且会重叠多个工作实例,因此它们不会受到延迟限制。预计您将并行使用多个内核。

除了内存限制您可以使用的缓冲区数量之外,似乎没有“硬”限制。当为 UI 和计算使用相同的 GPU 时,您必须限制您的工作。根据我的经验,发布过多的工作会导致 GUI 和/或计算内核的饥饿。似乎没有任何方法可以确保您不会出现饥饿(工作项目开始实际执行之前的长时间延迟)。一些工作项可能会停留很长时间(在糟糕的情况下为 10 秒或更长时间),而 GPU 会执行其他工作项。我推测项目会根据数据可用性被分派到管道中,并且很少或没有任何东西可以防止工作项目的饥饿。

通过让 GPU 将其工作队列几乎/有时清空,从而减少 GUI 绘图工作项饥饿延迟,从而极大地提高了 GUI 响应速度。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-12-31
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多