OpenCL 内核上的 GPU 性能缓慢
Slow GPU performance on OpenCL kernel
我对 AMD GPU（Hawaii 核心或 Radeon R9 390）上的 OpenCL 的一些性能有点迷茫。
操作如下：
- 将内存对象 #1 发送到 GPU
- 执行内核#1
- 将内存对象 #2 发送到 GPU
- 执行内核#2
- 将内存对象 #3 发送到 GPU
- 执行内核#3
依赖是：
- 内存对象 #1 上的内核 #1
- 内存对象#2 上的内核#2 以及内核#1 的输出内存
- 内存对象#3 上的内核#3 以及内核#1 和#2 的输出内存
内存传输和内核执行在两个独立的命令队列中执行。命令依赖性由 OpenCL 中定义的 GPU 事件完成。
现在循环整个操作只是为了使用相同的输入数据进行性能分析。
如您在时间轴中所见，主机在 GPU 上等待很长时间以完成 clWaitForEvents()，而 GPU 大部分时间都处于空闲状态。您还可以看到重复的操作。为了方便起见，我还提供了所有已发出的 OpenCL 命令的列表。
我现在的问题是：
为什么GPU空转这么多？在我的脑海中，我可以轻松地将所有 "blue" 项放在一起并立即开始操作。内存传输为 6 GB/s，这是预期的速率。
为什么内核执行这么晚？为什么内核 #2 和内核 #3 执行之间存在差距？
为什么内存传输和内核不是并行执行的？我使用 2 个命令队列，只有 1 个队列，性能更差。
只需在脑海中将所有命令放在一起（当然要保持依赖性，因此第一个绿色必须在第一个蓝色之后开始）我可以将性能提高三倍。我不知道为什么GPU这么慢。有人有见识吗？
一些数字运算
- 内存传输 #1 为 253 微秒
- 内存传输 #2 为 120 微秒
内存传输 #3 为 143 微秒——由于未知原因，它总是过高，它应该约为 #2 的 1/2 或在 70-80 微秒范围内
内核 #1 是 74 微秒
- 内核 #2 为 95 微秒
- 内核 #3 是 107 微秒
因为内核 #1 比内存传输 #2 快，内核 #2 比内存传输 #3 快，总时间应该是：
- 253 微秒 + 120 微秒 + 143 微秒 + 107 微秒 = 623 微秒
但是 clWaitForEvents 是
- 1758 µs -- 或大约 3 倍
是的，有一些损失，10%（60 微秒）我没问题，但 300% 太多了。
正如@DarkZeros 所说，您需要通过使用多个命令队列在时间线上重叠它们来隐藏内核排队开销。
Why is the GPU idling so much?
因为您正在使用 2 个命令队列，并且它们 运行 连续地（可能）处理使它们等待更长时间的事件。
如果一切都是串行的，你应该使用单队列。如果可以添加双缓冲或类似技术来推进计算，则应该让两个队列重叠操作。
Why are the kernels executed so late?
宽洞包括主机端延迟，例如排队命令、将命令刷新到设备、主机端算法和设备端事件控制逻辑。也许事件可以小到 20-30 微秒，但主机-设备交互的时间不止于此。
如果你摆脱事件并使用单队列，驱动程序甚至可以添加早期计算技术来填补这些空白，甚至在你将这些命令入队之前（可能）就像 CPU 进行早期分支（预测）一样。
Why are memory transfer and kernel not executed in parallel?
没有强制执行，但驱动程序还可以检查内核和副本之间的依赖关系并保持数据完整，它们可以暂停某些操作，直到其他一些操作完成（可能）。
你确定内核和缓冲区副本是完全独立的吗？
另一个原因可能是两个队列没有太多可以重叠的选择。如果两个队列都有两种类型的操作，它们将有更多的选项可以重叠，例如 kernel + kernel，copy + copy 而不仅仅是 kernel + copy。
如果程序有太多小内核，您可以尝试 OpenCL 2.0 动态并行，它使设备调用内核本身比主机端排队更快。
也许您可以添加更高级别的并行性，例如图像级并行性（如果您进行图像处理）以保持 gpu 忙碌。同时处理 5-10 张图像，这应该确保独立 kernel/buffer 执行，除非所有图像都在同一个缓冲区中。如果这不起作用，那么您可以启动同一程序的 5-10 个进程（进程级并行性）。但是上下文过多可能会卡在驱动程序限制中，因此图像级并行性必须更好。
R9 390 必须能够处理 8-16 个命令队列。
1758 µs
有时即使是空内核也会让它等待 500-100 微秒。很可能你应该排队 1000 个周期，最后等待一次。如果每个循环在用户单击按钮后工作，则用户不会注意到 1.7 毫秒的延迟。
- 使用很多队列。
- 删除队列之间的事件（如果有的话）。
- 让每个队列做各种工作。
- 在主机端等待事件之前有多次迭代。
- 如果 OpenCL 2.0 存在，也尝试设备端入队，但这仅适用于内核执行，不适用于副本 to/from 主机。
我对 AMD GPU（Hawaii 核心或 Radeon R9 390）上的 OpenCL 的一些性能有点迷茫。
操作如下：
- 将内存对象 #1 发送到 GPU
- 执行内核#1
- 将内存对象 #2 发送到 GPU
- 执行内核#2
- 将内存对象 #3 发送到 GPU
- 执行内核#3
依赖是：
- 内存对象 #1 上的内核 #1
- 内存对象#2 上的内核#2 以及内核#1 的输出内存
- 内存对象#3 上的内核#3 以及内核#1 和#2 的输出内存
内存传输和内核执行在两个独立的命令队列中执行。命令依赖性由 OpenCL 中定义的 GPU 事件完成。
现在循环整个操作只是为了使用相同的输入数据进行性能分析。
如您在时间轴中所见，主机在 GPU 上等待很长时间以完成 clWaitForEvents()，而 GPU 大部分时间都处于空闲状态。您还可以看到重复的操作。为了方便起见，我还提供了所有已发出的 OpenCL 命令的列表。
我现在的问题是：
为什么GPU空转这么多？在我的脑海中，我可以轻松地将所有 "blue" 项放在一起并立即开始操作。内存传输为 6 GB/s，这是预期的速率。
为什么内核执行这么晚？为什么内核 #2 和内核 #3 执行之间存在差距？
为什么内存传输和内核不是并行执行的？我使用 2 个命令队列，只有 1 个队列，性能更差。
只需在脑海中将所有命令放在一起（当然要保持依赖性，因此第一个绿色必须在第一个蓝色之后开始）我可以将性能提高三倍。我不知道为什么GPU这么慢。有人有见识吗？
一些数字运算
- 内存传输 #1 为 253 微秒
- 内存传输 #2 为 120 微秒
内存传输 #3 为 143 微秒——由于未知原因，它总是过高，它应该约为 #2 的 1/2 或在 70-80 微秒范围内
内核 #1 是 74 微秒
- 内核 #2 为 95 微秒
- 内核 #3 是 107 微秒
因为内核 #1 比内存传输 #2 快，内核 #2 比内存传输 #3 快，总时间应该是：
- 253 微秒 + 120 微秒 + 143 微秒 + 107 微秒 = 623 微秒
但是 clWaitForEvents 是
- 1758 µs -- 或大约 3 倍
是的，有一些损失，10%（60 微秒）我没问题，但 300% 太多了。
正如@DarkZeros 所说，您需要通过使用多个命令队列在时间线上重叠它们来隐藏内核排队开销。
Why is the GPU idling so much?
因为您正在使用 2 个命令队列，并且它们 运行 连续地（可能）处理使它们等待更长时间的事件。
如果一切都是串行的，你应该使用单队列。如果可以添加双缓冲或类似技术来推进计算，则应该让两个队列重叠操作。
Why are the kernels executed so late?
宽洞包括主机端延迟，例如排队命令、将命令刷新到设备、主机端算法和设备端事件控制逻辑。也许事件可以小到 20-30 微秒，但主机-设备交互的时间不止于此。
如果你摆脱事件并使用单队列，驱动程序甚至可以添加早期计算技术来填补这些空白，甚至在你将这些命令入队之前（可能）就像 CPU 进行早期分支（预测）一样。
Why are memory transfer and kernel not executed in parallel?
没有强制执行，但驱动程序还可以检查内核和副本之间的依赖关系并保持数据完整，它们可以暂停某些操作，直到其他一些操作完成（可能）。
你确定内核和缓冲区副本是完全独立的吗？
另一个原因可能是两个队列没有太多可以重叠的选择。如果两个队列都有两种类型的操作，它们将有更多的选项可以重叠，例如 kernel + kernel，copy + copy 而不仅仅是 kernel + copy。
如果程序有太多小内核，您可以尝试 OpenCL 2.0 动态并行，它使设备调用内核本身比主机端排队更快。
也许您可以添加更高级别的并行性，例如图像级并行性（如果您进行图像处理）以保持 gpu 忙碌。同时处理 5-10 张图像，这应该确保独立 kernel/buffer 执行，除非所有图像都在同一个缓冲区中。如果这不起作用，那么您可以启动同一程序的 5-10 个进程（进程级并行性）。但是上下文过多可能会卡在驱动程序限制中，因此图像级并行性必须更好。
R9 390 必须能够处理 8-16 个命令队列。
1758 µs
有时即使是空内核也会让它等待 500-100 微秒。很可能你应该排队 1000 个周期，最后等待一次。如果每个循环在用户单击按钮后工作，则用户不会注意到 1.7 毫秒的延迟。
- 使用很多队列。
- 删除队列之间的事件（如果有的话）。
- 让每个队列做各种工作。
- 在主机端等待事件之前有多次迭代。
- 如果 OpenCL 2.0 存在，也尝试设备端入队，但这仅适用于内核执行，不适用于副本 to/from 主机。