使用 clEnqueueMapBuffer 和“查询命令是否完成”的 OpenCL 主机的内存可见性答案

【问题标题】：Memory visibility for the OpenCL host using clEnqueueMapBuffer and 'querying whether the command has finished'使用 clEnqueueMapBuffer 和“查询命令是否完成”的 OpenCL 主机的内存可见性
【发布时间】：2017-03-13 21:52:09
【问题描述】：

OpenCL 1.1 标准说 (5.2.3)：

如果blocking_map 为CL_FALSE，即map 操作是非阻塞，则指针指向映射区域在映射命令完成之前不能使用由 clEnqueueMapBuffer 返回的区域。事件参数返回一个事件对象，可用于查询执行情况 map 命令的状态。地图命令完成后，应用程序可以使用 clEnqueueMapBuffer 返回的指针。

但在（5.9，紧跟在表 5.15 之后）中有以下语句：

使用 clGetEventInfo 确定事件标识的命令是否已完成执行（即 CL_EVENT_COMMAND_EXECUTION_STATUS 返回 CL_COMPLETE) 不是同步点。有没有保证被命令修改的内存对象与事件关联的其他命令将可见。

Q1：所以，我想知道是否有其他方法可以“查询执行 map 命令的状态”以及当查询返回 'CL_COMPLETE' 时是否保证内存一致性（在本例中为主机）？
Q2：我错过了什么吗？
Q3：针对这种情况的典型 OpenCL 习惯用法是什么？

【问题讨论】：

标签： multithreading parallel-processing opencl

【解决方案1】：

1- 使用入队屏障并从该命令中获取您的事件，以便与主机具有可见性和细粒度同步

在while循环中等待它查询使用更多的cpu，但至少是细粒度的

2- 细粒度控制的事件。可见性的等待和障碍

例如 clwaitforevents 两者都提供，使用的 CPU 更少，但粒度比查询更大

设备端只使用事件网络在队列之间绘制图表

3- 没有任何典型。选择最适合您的问题的一种

【讨论】：

所以，看起来我需要另一个“机器”来提供内存可见性保证。嗯，“细粒度”是指 clWaitForEvents 比轮询相应事件产生更多开销，对吧？
事件网络不是也用于在乱序队列中包含任务图吗？对此类队列的支持是一种普遍的选择吗？
是的，等待时间更长。多队列同步对于事件来说是最快的，并且乱序不是强制选项。
可选，是的。但有趣的是，是否可以从供应商处获得乱序队列的实现。根据我们之前的讨论，我得出的结论是，您拥有许多供应商实施的经验。
@parallelgeek 我已经在 amd gpu 上尝试了 ooo queue，它只是忽略了它然后我没有尝试在 intel 上，因为 amd 已经领先于 opencl。英伟达也在远处跟随。我没有nvidia，但几年前有一些论坛的人尝试过我的程序。查询 CL_DEVICE_QUEUE_PROPERTIES 是否返回带有 ooo_enable 的值。即使它返回该值，如果它仍然按顺序执行，我也不会感到惊讶。 Opencl 规范只说“不能保证命令是按顺序发出的”，这也暗示“不能保证它不会乱序”