问题标签 [nvprof]

CPU 和 GPU（黄色块）中内核启动的开始和结束的定义是什么？他们之间的界限在哪里？

请注意CPU和GPU中那些黄色块的开始，结束和持续时间是不同的。为什么CPU调用vecAdd<<<gridSize, blockSize>>>(d_a, d_b, d_c, n);需要那么长时间？

CPU黄块：

GPU黄块：

如何解决在nvprof可用空间相对较少的磁盘上运行时发生的崩溃？

具体来说，在分析我的 cuda 内核时，我使用以下两个命令：

第一个nvprof命令工作正常。第二个nvprof需要写入一个 12GB 的临时文件/tmp才能继续。由于我的 38GB 云盘只有 6GB 可用，所以nvprof崩溃了。假设我无法释放更多磁盘空间，我该如何解决这个问题？

旁注： 这与诊断问题几乎无关，但 nvprof 报告的Error: Application received signal 7是“总线错误（内存访问错误）”（参见http://man7.org/linux/man-pages/man7/signal.7 .html了解更多信息）。

有没有办法让 CUDA在其统计分析器nvprof中包含函数调用？malloc

我一直在努力提高我的应用程序的性能。自然地，我一直在使用nvprof它作为工具。

最近，为了减少我的应用程序的 GPU 内存占用，我编写了使其运行时间增加一倍的代码。然而，导致速度变慢的新代码在分析器中只出现了少量（指令采样表明大约 10% 的时间都花在了新代码中，但一个天真的想法会表明 50 % 的时间应该花在新代码上）。也许新代码导致更多的缓存抖动，也许将实现放在头文件中，这样它就可以被内联混淆探查器等。但是，没有充分的理由，我怀疑新代码对malloc.

事实上，在我减少malloc调用次数后，我的性能提高了，几乎回到了合并新代码之前的水平。

这让我想到了一个类似的问题，为什么malloc统计分析器中没有显示 的​​调用？ 这些malloc调用是某种无法观察到的 GPU 系统调用吗？

下面，我包含一个示例程序及其展示这个特定问题的输出。

结果的省略版本是：

分析结果如下图所示。将鼠标悬停在浅蓝色条上时显示的数字与条的大小一致。具体来说，第 41 行有 16,515,077 个与之关联的样本，但第 47 行只有 633,996 个样本。

顺便说一句，上面的程序是用调试信息编译的，可能没有优化——在 Nsight Eclipse 中编译的默认“调试”模式。如果我在“发布”模式下编译，则会调用优化，并且countup()调用的持续时间非常接近 0 秒。

我正在尝试使用 nvprof 工具分析我的 CUDA 程序。

这是我的代码：

我使用命令 nvcc add.cu -o add_cuda 编译它。

然后我使用 nvprof ./add_cuda --unified-memory-profiling off 或 nvprof 运行它（以 root 身份）并获得以下输出：

我在网上搜索了一个解决方案nvprof 没有接收任何 API 调用或内核，https: //devtalk.nvidia.com/default/topic/1010691/visual-profiler/nvprof-error-code-139-but-memcheck-ok/ ，但实际上没有任何帮助。

我怎样才能让 nvprof 工作？

谢谢！

Fedora 29 64 位

英伟达-smi

我正在尝试使用 nvprof 来监控 GPU 的性能。我想知道 HtoD（主机到设备）、DtoH（设备到主机）和设备执行的耗时。它与 numba cuda 网站的标准代码配合得很好：

这是来自 nvprfo 的结果：

但是，当我使用以下代码添加多处理的用法时：

nvprof 似乎在监视该过程，但它没有任何结果，尽管它报告 nvprof 正在分析：

此外，当我使用 Ray（用于进行分布式计算的包）时：

nvprof 没有显示任何内容！它甚至没有显示 nvprof 正在分析进程的行（但代码确实已执行）：

有谁知道如何解决这个问题？或者我还有其他选择来获取这些数据以进行分布式计算吗？

关于加载/存储指令有两个nvprof指标，它们是ldst_executed和ldst_issued。我们知道executed<=issued。我希望那些发出但未执行的加载/存储与分支预测和其他不正确的预测有关。但是，从这个（幻灯片 9）文档和这个主题中，发出但未执行的指令与序列化和重放有关。

我不知道这个原因是否适用于加载/存储指令。此外，我想知道为什么这样的术语用于已发出但未执行的指令？如果出于某种原因存在序列化，则会多次执行指令。那么，为什么它们不被视为executed？

对此有何解释？

“占用图”中显示的 SM 是否对应blockIdx.x或注册%smid？

这是此类图表的示例

这是我将 打印blockIdx.x为“逻辑”块并将寄存器%smid（通过程序集访问）打印为物理块时的一些示例输出。

此外，我可以预测每个块需要多长时间才能执行，并且不预测 ~30 和 ~31 块需要很长时间——即使它们在图表上显示为需要很长时间。并且我“预测”需要“短时间”的一些块比“短时间”需要更长的时间，如图所示。因此，逻辑块和所采用的持续时间之间似乎存在不匹配，如图所示。

最后，鉴于图中使用了术语“SM”，我希望该图表示物理 SMID，而不是逻辑块号。

鉴于这三个证据，我怀疑图中显示的数字对应于寄存器%smid。

我正在寻找的只是确认。一旦我完全理解了这个问题，我将有理由更好地在现有的 80 个块中分配工作，或者只是使用更多块开始。谢谢！

nvprof用于测量我的示例内核的浮点运算，似乎没有度量标准flop_count_dp_div，而实际的双精度除法运算是根据双精度的 add/mul/fma 甚至一些单精度的 fma 来测量的操作。

我想知道为什么会这样，nvprof如果我没有源代码，如何从报告中推断出内核的动态除法操作数？

我的简单测试内核：

以及nvprof两个内核的输出：

我nvprof.exe在初始化数据的函数上运行，调用三个内核并释放数据。所有的配置文件都应该这样，我得到了这样的结果：

如您所见，在GPU activities. 这是源代码：

之后，我将初始化数据、内核调用和释放数据提取到单独的主机函数并nvprof再次调用。结果我只得到了有关 API 调用的信息，如下所示：

如您所见，也没有 section Unified Memory profiling result，所以我尝试像这样运行 nvprofnvprof.exe --unified-memory-profiling off .\a.exe但得到了相同的结果。源代码：

更新：我发现了问题，我在数组中运行了包含 10000000000 个元素的代码，看起来甚至没有调用内核。因为我用 10000000 (10^8) 个元素运行它们，并且用了将近 3 秒的时间来完成，并且用 10000000000 (10^10) 元素立即完成。但是没有错误哦。

我应该如何捕捉这种情况？

当我在 pytorch 中使用 os.environ['CUDA_VISIBLE_DEVICES'] 时，我收到以下消息

这实际上意味着什么？如何通过使用“CUDA_VISIBLE_DEVICES”（不是 torch.cuda.set_device()）来避免这种情况？

这是 pytorch test.py 中的代码

和命令：