OpenCL 事件歧义答案

【问题标题】：OpenCL events ambiguityOpenCL 事件歧义
【发布时间】：2016-10-10 21:04:19
【问题描述】：

参考clGetEventProfilingInfo 文档，cl_event 源自clEnqueueNDRangeKernel 可能是：

CL_PROFILING_COMMAND_QUEUED

当事件标识的命令被排队在命令队列中时主人。

CL_PROFILING_COMMAND_SUBMIT

当已入队的事件标识的命令是由主机提交到与命令队列关联的设备。

CL_PROFILING_COMMAND_START

当事件标识的命令开始在设备上执行时。

CL_PROFILING_COMMAND_END

当事件标识的命令已完成在设备。

假设可视化整个内核分析：

COMMAND_QUEUED -> COMMAND_SUBMIT -> COMMAND_START -> COMMAND_END

&对应的时间线：

Queueing -> Submitting -> Executing

地点：

排队 = COMMAND_SUBMIT - COMMAND_QUEUED
提交 = COMMAND_START - COMMAND_SUBMIT
正在执行 = COMMAND_END - COMMAND_START

问题：
我之前的方程式是否正确？如果是这样，排队和提交之间的真正区别是什么？换句话说，如果我想把整个过程分为 COMMUNICATION（卸载）时间和 COMPUTATION（执行）时间，什么他们的方程会是什么？

【问题讨论】：

标签： parallel-processing opencl gpu

【解决方案1】：

您的解释似乎相当正确。 QUEUED 是当您调用 OpenCL API（例如 clEnqueueNDRangeKernel）时。提交是运行时将工作交给设备的时间。 START 是开始执行的时间，END 是执行完成的时间。这四次之间有三种状态。第一个状态在主机上是空闲的。第二个状态在设备上是空闲的。第三个状态是在设备上执行。如果您希望将前两个组合成“通信”，则将它们加在一起（或使用 COMMAND_START - COMMAND_QUEUED）。

【讨论】：

在 CPU 上运行时，QUEUED=0 但 SUBMIT 不是！为什么？
不知道为什么。听起来像是实现中的一个错误。
我怀疑因为 gpu 上的数字不同，提交比排队需要更多时间！什么实现，这些读数来自实际的执行分析！
您说的是 COMMAND_QUEUED，所以我认为您的意思是请求 CL_PROFILING_COMMAND_QUEUED 返回的值是 0，这将是实现（运行时）中的错误。相反，如果您的意思是 CL_PROFILING_COMMAND_QUEUED 和 CL_PROFILING_COMMAND_SUBMIT 的值相同，则将计算值“排队”设为 0，那就没问题了。这只是意味着运行时在该状态下没有花费任何时间并在您调用 API 时提交。
CPU 中的队列为 0，因为当 CPU 中只有一个任务时没有队列。但是，如果您之前运行过内核，则排队不会为 0。GPU 不同，因为它们是异步的，所以无论如何您总会得到一些排队时间。

【解决方案2】：

我之前的方程式正确吗？

是的。

如果是这样，排队和提交之间的真正区别是什么？换句话说，如果我想将整个过程分为 COMMUNICATION（卸载）时间和 COMPUTATION（执行）时间，它们的方程是什么？

排队：

等待其他任务完成以启动当前任务所花费的时间。换句话说，等待所有相关事件的 CL_COMPLETE 状态，或者在当前排队的队列中有空闲资源。
注意：CPU 排队到空闲设备时的排队时间为 0，因为它们是同步的。虽然 GPU 总是会有一些小的排队时间（由于异步行为）。这就是尽可能多地流水线到 GPU 设备的原因。

提交：

准备当前任务（编译 LLVM、移动缓冲区、准备设备核心等）所花费的时间应该很小，但不是 0。

如果您正在寻找公式，则只有“提交”和“执行”对计算当前任务开销有效。忽略排队，因为它不依赖于您的任务：

Active% = Executing/(Executing+Submitting)
Overhead% = Submitting/(Executing+Submitting)

【讨论】：