问题标签 [nsight-compute]

两个问题：

1. 根据 Nsight Compute，我的内核是计算受限的。相对于峰值性能的 SM 利用率百分比为 74%，内存利用率为 47%。但是，当我查看每个管道利用率百分比时，LSU 利用率远高于其他管道（75% 对 10-15%）。这不是表明我的内核受内存限制吗？如果计算和内存资源的利用率与管道利用率不对应，我不知道如何解释这些术语。

2. 调度程序仅每 4 个周期发布一次，这是否意味着我的内核受延迟限制？人们通常根据计算和内存资源的利用率来定义它。两者之间有什么关系？

我跑：

...什么都没有出现。为什么？

（这su是由于权限问题，这不是这个错误的原因。）

当您使用 NSight-Compute 的 Source、PTX 或 SASS 视图时，您会看到每行采集的样本数。但是，您看不到（或很难找到）总体上采集的样本总数，您希望将其标准化。

它是不是有点不起眼，还是只是丢失了？

假设我有一个myapp不需要命令行参数的可执行文件，并启动一个 CUDA kernel mykernel。我可以调用：

并获得如下所示的输出：

到目前为止，一切都很好。mykernel但是现在，我只想要- 而没有其他输出的整体内核持续时间。看着nv-nsight-cu-cli --query-metrics，我看到，除其他外：

所以，它一定是其中之一，对吧？但是当我跑步时

我得到：

我的问题：

• 为什么我得到“n/a”值？
• 我怎样才能得到我所追求的实际价值，而不是别的？

备注：：

• 我将 CUDA 10.2 与 NSight Compute 版本 2019.5.0（内部版本 27346997）一起使用。
• 我意识到我可以过滤不合格调用的标准输出流，但这不是我想要的。
• 我实际上只想要原始数字，但我愿意接受并使用--csv最后一个字段。
• 在nvprof 过渡指南中找不到任何相关内容。

我正在使用 NVRTC 编译内核。相关的 API 调用是：

如您所见，源是原始字符串，与文件无关。这意味着当你--generate-line-info，你得到行号，但没有相关的文件名。这意味着如果您随后使用 NSight Compute - 您将无法看到您的内核源代码。

显然，无论是 NSight Compute 本身还是 NVRTC 本身，都无法确定原始源镜像在某个文件中。但是必须有一些方法来解决这个问题：

• 也许我在 NVRTC API 中遗漏了一些可以使源 <-> 文件关联的东西？
• 也许我们可以操纵生成的编译程序（合理地，而不是手动，或编写我自己的新 API）来建立关联？
• 也许我们可以以某种方式将源代码推入编译的程序中？

我在我的 cuda 内核上运行了 cuda-11.2 nsight-compute 。

它报告说 SOL SM 为 79.44%，我认为这非常接近最大值。SOL L1 为 48.38%

当我检查屋顶曲线图时，我发现我的测量结果与峰值性能相差甚远。

达到：4.7 GFlop/s 。

车顶线峰值：93 GFlop/s 左右。

我还看到 ALU 管道利用率为 80+%

那么，如果 ALU 管道被充分利用，为什么根据车顶线图实现的性能会低很多呢？

请注意，这是在 RTX 3070 上，单精度峰值为 17.6 TFlop/s：

更新

我想我知道这里发生了什么……@robert-crovella 让我走上了正确的轨道，表明 ALU 是整数运算，因此不包括在内。而且这些并不是唯一不包括在内的操作！

屋顶线图仅显示 fp32 和 fp64 操作，而不显示 fp16 操作。

我的代码使用半精度浮点数，我怀疑屋顶线图不适用于我的代码。

我需要在本地设置一个通过 SSH 连接到 EC2 实例的工具，以在远程机器上执行分析。问题如下：EC2 需要使用 PEM 证书进行连接，但该工具不支持证书。有没有办法进行一些端口转发，以便该工具可以在没有密码（或至少没有证书）的情况下连接到类似 localhost:2222 的东西，然后流量被重定向到 EC2？

我不确切知道该工具使用了哪些端口，但可以肯定它可以通过 SSH 传输所有流量。

如果您需要更多信息，该工具是 Nvidia Nsight Compute。

我试过 sh -L 2222:localhost:22 -i mycertificate.pem <username_ec2>@<ip_ec2> 但后来ssh <username_ec2>@localhost:2222返回ssh: Could not resolve hostname localhost:2222: nodename nor servname provided, or not known。

CUDA Profiling Guide列出了采样 warp 失速的各种原因，例如分配、障碍、LG Throttle 等。并且 - NSight Compute 分析器将这些分布显示为分析结果的一部分。

问题是，一些失速原因被列为仅从某些计算能力开始支持，例如“LG Throttle：7.0+”

我的问题：当停顿原因是这种“不受支持”的原因时，具有较早计算能力的设备会发生什么？或者，换句话说，列出的每个失速原因的回退是什么？

在 Ye Olde NVIDIA Visual Profiler 中，我们有一个“其他”停滞原因，请参阅：

Nsight 分析器显示的“其他”问题停顿原因是什么？

但我在（我的版本）NSight Compute 中没有看到这一点。

借助最近的 NVIDIA 微架构，出现了一种新的 (?)翘曲停止原因/翘曲调度程序状态分类法。

此分类中的两个项目是：

• Short scoreboard - 记分板依赖于 MIO 队列操作。
• 长记分牌- 记分牌依赖于 L1TEX 操作。

其中，我认为“记分板”是指乱序执行数据依赖跟踪的含义（参见例如此处）。

我的问题：

• 形容词“短”或“长”描述了什么？它是单个记分牌的长度吗？两种不同操作的两个不同记分牌？
• MIO 之间这种有点不直观的二分法的含义是什么——其中一些，但不是全部是内存操作；和L1TEX操作，都是内存操作？只是因为停顿原因而二分法，还是与实际硬件有关？

根据此链接https://docs.nvidia.com/nsight-compute/ProfilingGuide/index.html：

Warp 在等待 MIO（内存输入/输出）指令队列未满时停止。在极端使用 MIO 流水线（包括特殊数学指令、动态分支以及共享内存指令）的情况下，这种停顿的原因很高。

根据这一https://docs.nvidia.com/drive/drive_os_5.1.12.0L/nsight-graphics/activities/index.html：

可能由本地、全局、共享、属性、IPA、索引恒定负载 (LDC) 和解耦数学触发。

我的理解是所有的内存操作都是在 LSU 上执行的，所以我会想象它们一起存储在同一个指令队列中，然后由 LSU 单元执行。由于它们都排在一起，因此第二种解释（包括全局内存访问）对我来说更有意义。问题是，如果是这样的话，LG Throttle 就没有必要了。

MIO Throttle 究竟意味着什么？所有内存指令是否都存储在同一个队列中？