OpenCL的事件歧义

参照clGetEventProfilingInfo文档，cl_event源于clEnqueueNDRangeKernel可以是：OpenCL的事件歧义

CL_PROFILING_COMMAND_QUEUED

当由事件标识的命令由排队在命令队列主人。

CL_PROFILING_COMMAND_SUBMIT

当已经排队由事件标识的命令是由主机提交与commandqueue相关联的设备。

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（执行）时间，那么什么是将是它们的等式？

来源

2016-10-07 Ahmed Ghoneim

你的解释看起来相当真实。 QUEUED是当你调用OpenCL API时（比如clEnqueueNDRangeKernel）。 SUBMIT是运行时将工作交给设备的时间。 START是开始执行时，END是执行完成时。这四次之间有三种状态。第一个状态在主机上空闲。第二个状态在设备上空闲。第三个状态在设备上执行。如果您希望将前两者合并为“沟通”，则将它们加在一起（或使用COMMAND_START - COMMAND_QUEUED）。

来源

2016-10-08 00:43:29 Dithermaster

当在CPU上运行时，QUEUED = 0但是SUBMIT不是！为什么？ –

不知道为什么。听起来像是实施中的一个错误。 – Dithermaster

我怀疑因为gpu上的数字不同，提交需要比排队更多的时间！什么实现，这些读数来自实际执行分析！ –

我以前的方程是真的？

是的。

如果是这样，排队和提交的真正区别是什么？换句话说，如果我想把整个过程分成通信（卸载）时间和计算（执行）时间，它们的方程是什么？

队列：

时间花费在等待其他任务，以启动当前一个结束。换句话说，等待所有依赖事件的CL_COMPLETE状态，或者在当前排队队列中有空闲资源。
注意：排队等待空闲设备时，CPU将有0个队列时间，因为它们是同步的。尽管GPU总是会有一些小的排队时间（由于异步行为）。这就是尽可能多地向GPU设备传输数据的原因。

提交：

花费的时间准备当前的任务（编译LLVM，移动缓冲区，准备设备核等），要小，但不为0

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

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

来源

2016-10-10 13:04:19 DarkZeros

OpenCL的事件歧义

回答

相关问题