C++ 混合隐式和显式CUDA流

我有一些CUDA 8.0代码（编辑：我继承的，不是我写的东西），基本上如下所示：

cudaMemcpy(devInputData, ..., cudaMemcpyHostToDevice);
kernelThings<<<GRIDS, BLOCKS, 0, myStream>>>(devInputData);
cudaDeviceSynchronize();

两个函数之间有16微秒的间隔。此行为在应用程序中重复多次

但是，我接下来删除了

cudaDeviceSynchronize（）

，重新运行了

Nsight

，发现现在它们重叠了：

[Memcpy HtoD]
         [kernelThings]

内核现在在

cudaMemcpy

完成前10微秒启动

显然，正确的修复方法是将流与

cudaMemcpyAsync（）

一起使用：

cudaMemcpyAsync(devInputData, ..., cudaMemcpyHostToDevice, myStream);

---

但是，我的问题是，为什么在使用

cudaDeviceSynchronize（）

时没有看到进程重叠？简单的回答是，如果使用不同版本的CUDA或GPU，我可能就没那么幸运了。

不要依赖隐式/默认流和ops的拐杖以及它们的同步行为。对于您的第一个“Hello world”级别的程序，这可能很方便，但正如您自己所注意到的，您必须成为API律师或通灵师，才能猜测在某些复杂场景中会发生什么

只需确保内核中使用的每个缓冲区是：

由同一命令队列上的上一个操作填充，或

2.1如果是输入缓冲区-有一个事件对，确保在内核启动到另一个流之前发生任何影响缓冲区的事情，以及 2.2如果是输出缓冲区-有一个事件对，确保在其他地方使用输出缓冲区之前执行内核

---

“cudaMemcpy（）在没有流的情况下同步工作，所以据我所知，这段代码是正确的。”我认为这不能用用户代码来解释。

cudaMemcpy

调用被阻塞，但传输量非常小。除非您遇到这种情况，否则从理论上讲，内核启动无法以主机执行顺序抢占内存拷贝。事实上，不同的溪流并不重要。我的猜测是，你在这里看到了驾驶员的副作用。如果驱动程序批处理命令（现代WDDM驱动程序肯定会，其他人可能会），那么用户代码隐式同步行为肯定有可能会发生变化。我怀疑这个问题是否可以在没有命令的情况下权威地回答，我建议包括其他细节，如平台和GPU类型、计算模式、，和编译命令。例如，如果这种情况在应用程序中多次发生，那么您可能会看到与

cudaMemcpy

调用之前发出的内核重叠。删除

cudaDeviceSynchronize（）

与这个理论是一致的。我应该提到这段代码是继承的代码，而不是我自己写的东西，所以这就是我试图理解它（某种程度上）工作的原因。我不明白这到底是如何回答这个问题的asked@talonmies：它提出了一种解决问题的方法“混合隐式和显式CUDA方案”，这避免了OP面临的不确定性。“我的问题是，为什么在使用cudaDeviceSynchronize（）时，我没有看到进程重叠？”

cudaMemcpyAsync(devInputData, ..., cudaMemcpyHostToDevice, myStream);