OpenCL并行化成本

Question

我为OpenCL搭建了一个Freescale i.MX6.Q平台，我得到了一些有趣的结果，我无法完全解释。我的算法是通过执行4个内核来完成的，最后一个是我感兴趣的一个:经典的图像差异。

我测试了两个版本，一个向量化版本和一个经典版本(没有矢量化)。首先，我对结果感到惊讶，给出了并行化的结果:在这个平台上，只能选择OpenCL来处理包含180 this以上的图像(在算法中，图像作为缓冲区处理)。

但是，对于这两个OpenCL实现，在开始时(对于小图像)有常量执行时间(大约5ms)。我检查了一个空内核的执行时间，在这个平台上，对于任何经过测试的映像(从32x32到1920x1024)，它们总是在5ms左右。

我将空内核的这些时间看作是一个OpenCL差异的并行化成本，我想知道这个代价包含了什么？

我的内核编译是在工作台之外完成的，我看不出哪一步应该使用5ms。是否只有GPU正在处理的NDRange解释？

如果有人对此有解释，我就接受！

巴普蒂斯特

编辑：

我的时间测量和内核发布：

start_time = time_now();

cl_mem_flags mem_device_host;
if (device.getInfo<CL_DEVICE_HOST_UNIFIED_MEMORY>()==CL_TRUE)
    mem_device_host = CL_MEM_USE_HOST_PTR;
else
    mem_device_host = CL_MEM_COPY_HOST_PTR;

cl_status = kernel.setArg(0, input_image);
oclReturnOnError(cl_status, "Passage de l'argument 0 du kernel 'morph'")

cl_status = kernel.setArg(1, output_image);
oclReturnOnError(cl_status, "Passage de l'argument 1 du kernel 'morph'")

cl_status = kernel.setArg(2, input_SE);
oclReturnOnError(cl_status, "Passage de l'argument 2 du kernel 'morph'")

cl::Event eventMorph;
cl_status = commandQueue.enqueueNDRangeKernel(kernel,
    cl::NullRange,
    global_range,
    local_range
    NULL , &eventMorph);
oclReturnOnError(cl_status, "Ajout du kernel 'morph' à la queue de commande")

cl_status = eventMorph.wait();
oclReturnOnError(cl_status, "Attende d'exécution du kernel 'morph'")

end_time = time_now();

Answer 1

您的问题主要是如何保证内核的执行。使用OS time_now()会给您带来糟糕的分辨率，并且不是测试OpenCL性能的方法。

此外，主机缓慢地参加GPU的工作负载。因此，如果您排队，不要强制执行(使用clFlush())，然后被动地等待完成，结果是性能非常差。因为您必须等待所有队列并提交，所以您将看到调用和实际执行之间的大量开销。

该run+wait模型对于示例和演示是有效的，但不应用于实际系统或性能度量。

测量性能的正确方法是使用event。您可以使用cl::Event.getProfilingInfo<CL_PROFILING_COMMAND_START>()和cl::Event.getProfilingInfo<CL_PROFILING_COMMAND_END>()来度量内核的开始和结束时间。

运行系统的正确方法是，只在需要提取数据时(通常在EnqueueReadBuffer())强制进行阻塞调用。这样，如果您排队的一系列内核，他们将运行一个接一个，几乎没有空闲时间在他们之间。