CUDA：为什么有大量GPU空闲时间？

问题

总GPU时间+总CPU开销小于总执行时间。为什么?

细节

我正在研究全局内存访问和内核启动的频率对性能的影响，我设计了一个代码，其中包含多个小内核和总计约10万个内核调用。每个内核从全局内存中读取数据，对其进行处理，然后写回全局内存。正如预期的那样，代码运行速度比原始设计慢得多，原始设计只有一个大内核，很少启动内核

当我使用命令行探查器获取“gputime”（GPU内核或内存复制方法的执行时间）和“cputime”（非阻塞方法的CPU开销，阻塞方法的gputime和CPU开销之和）时，出现了这个问题。据我所知，所有GPUTIME和所有CPUTIME的总和应该超过整个执行时间（最后一个“gpuendtimestamp”减去第一个“gpustarttimestamp”），但事实恰恰相反（GPUTIME的总和=13.835064 s， cputimes之和=4.547344 s，总时间=29.582793）。在一个内核的结束和下一个内核的开始之间，通常会有大量的等待时间，比下一个内核的CPU开销还要大。大多数内核都有这个问题：memcpyDtoH、memcpyDtoD和推力internel函数，如按值启动、关闭、快速扫描等。可能的原因是什么

系统 Windows 7，TCC驱动程序，VS 2010，CUDA 4.2

---

谢谢你的帮助

这可能是分析（增加延迟）和Windows WDDM子系统的组合。为了克服后者的高延迟，CUDA驱动程序对GPU操作进行批处理，并通过单个Windows内核调用分组提交操作。如果CUDA API命令位于未提交的批中，这可能会导致GPU长时间处于非活动状态

---

（将@Talonmes的评论复制到答案中，以启用投票和接受。）

这可能是分析（增加延迟）和Windows WDDM子系统的组合。为了克服后者的高延迟，CUDA驱动程序对GPU操作进行批处理，并通过单个Windows内核调用分组提交操作。如果CUDA API命令位于未提交的批中，这可能会导致GPU长时间处于非活动状态。谢谢，@talonmies。我刚刚用smi检查了gpu设置，发现驱动模式已经在TCC中。我还单独运行了环境变量COMPUTE_PROFILE=0的可执行文件，总执行时间保持不变XS。在您的问题中，没有提到您正在使用TCC驱动程序是一个很大的遗漏。我使用Linux开发，与不使用评测的情况下运行相比，评测增加了15-40%的额外执行时间。当驱动程序和计数器设置、读取和重置事件时，大部分额外的时间都是空闲GPU时间。这个问题现在已经有3.5年的历史了-没有提供任何代码或严重的分析数据，并且不可能根据2012年发布的内容提供有用的答案。出于这些原因，我投票关闭了它。CUDA驱动程序在WDDM上批处理请求。Nsight Visual Studio Edition的下一个版本将显示此行为。此外，这些工具还会增加开销（每次API调用约1µs，每次启动约5-15µus）。对于内核启动，显示的时间只是内核执行的时间。这不包括安装开销。设置时间与您传递的参数数量（在CC 2.0+上高达4KB）、纹理/曲面绑定以及状态更改的数量（例如缓存配置）有关。Nsight VSE和Visual Profiler 5.0比CUDA命令行探查器更精确，开销更小。命令行探查器报告的cputime中是否已包含安装开销？现在我仍然不太明白为什么gputime（仅gpu上的内核执行时间）+cputime（开销）<总执行时间。@KingCrimson cputime（命令行探查器报告的）包含了在驱动程序API（而不是CUDA运行时API）中花费的大部分时间。除了CPU开销之外，还有GPU端（不在gputime中）没有考虑的开销。您只需增加传递给每次启动的参数数量即可观察到这一点。命令行探查器将每隔128到256个任务转储一次记录。这将增加cpu开销。我建议您使用Nsight VSE，因为开销较小，时间线显示与工具相关的开销。@KingCrimson如果您发布代码，我可以运行跟踪并向您提供其他信息。非常感谢@GregSmith。我会问我的主管是否允许发布代码。顺便说一句，我刚刚使用Nsight VSE和最新的nvprof再次运行跟踪。计时结果（总内核执行时间、总执行时间）与命令行探查器生成的结果相同。使情况复杂化的是，Nsight VSE报告的某些设备到设备mem拷贝时间为负值。也许某个柜台不知怎么溢出来了。