我一直在运行 CUDA 程序的内核。我观察到 GPU 计数器报告的时间与内核执行的 NVVP 之间存在相当大的差异。为什么通常会观察到这种差异?
1 回答
Nsight Visual Studio Edition 和 Visual Profiler 支持两种机制来捕获内核的持续时间。这两种方法都将导致比 CUevent/cudaEvent 报告的值更小、更准确。方法如下:
- 并发内核时序
这是 Nsight 2.x 和 Visual Profiler 5.0 用来生成时间线的默认模式。内核的持续时间定义为从内核代码开始在设备上执行到完成的时间。这无法使用 CUDA 事件来衡量。
- 序列化内核时序
这是工具在为每个内核收集 PM 计数器时使用的默认模式。内核的持续时间定义为 GPU 处理启动请求直到内核完成后 GPU 空闲的时间。此模式专门禁用并发内核执行。在几乎所有情况下,报告的持续时间都将略大于并发内核跟踪持续时间,因为它包括 GPU 启动第一个块的时间和 GPU 完成所有内存存储的时间。
- CUDA 事件范围计时
CUDA 事件计时是通过在内核在同一流上启动前后调用 cu/cudaEventRecord 来完成的。每个事件记录都会将一个命令插入 GPU 推送缓冲区。当命令到达 GPU 时,它会将时间戳写入内存。可以在不启动的情况下推送两个事件记录。这允许开发人员测量两个时间戳命令之间的 GPU 时间。这种方法有以下缺点,这就是为什么我鼓励开发人员使用这些工具(Nsight、Visual Profiler 和 CUPTI):
-
一种。提交启动事件记录和启动之间经过的时间可能会受到 CPU 开销的影响。Linux/TCC 上的启动开销为 5-8µs,而在 WDDM 上可能更高。
湾。GPU 可以在启动事件记录和内核执行之间进行上下文切换。
C。启动事件记录将包括启动开销,包括更新需要调整大小的驱动程序缓冲区的时间、复制参数、复制纹理绑定……
d。提交内核和结束事件记录之间经过的时间会影响时间。
e. GPU 可以在内核执行结束和结束事件记录之间进行上下文切换。
F。不正确地使用事件会破坏并发内核执行。
在每种模式中提供的持续时间将提供不同的值。此外,工具提供的持续时间的定义和通过使用事件可用的持续时间的定义是不同的。
NVIDIA 工具将持续时间尽可能定义为从 GPU 开始在内核上工作到 GPU 完成内核上的工作的时间。如果开发人员有兴趣收集这些信息,他们应该查看工具包中包含的 CUPTI SDK。