NvPerf GPU 性能计数器参考手册

本文档基于 NVIDIA 官方文档，对 NvProfAnalyzer 中使用的所有 GPU 性能计数器进行中文解释。

参考文档来源

• Nsight Compute Profiling Guide — 计数器命名规则、硬件单元、管线定义
• Nsight Graphics Advanced Learning — 图形管线各单元的功能说明
• Nsight Graphics System Architecture — GPU 系统架构图解
• NVIDIA Peak Performance Analysis Blog — 性能分析方法论
• Nsight Compute CLI — CLI 工具与指标映射表

一、计数器命名规则

NVIDIA 性能计数器遵循统一的命名格式：

单元__(子单元?)_(管线阶段?)_度量_(限定符?)

示例解读：

• sm__inst_executed

  • 单元: SM | 度量: inst_executed (指令执行) | 限定符: 无
  • → SM 执行的 warp 指令总数

• sm__inst_executed_pipe_fma

  • 单元: SM | 度量: inst_executed | 限定符: pipe_fma
  • → FMA 管线执行的 warp 指令数

• smsp__thread_inst_executed_pipe_tex_pred_on

  • 单元: SMSP | 度量: thread_inst_executed | 限定符: pipe_tex, pred_on
  • → TEX 管线中谓词开启的线程级指令数

• l1tex__t_bytes_pipe_tex_mem_texture_op_tex

  • 单元: L1TEX | 度量: t_bytes | 限定符: pipe_tex, mem_texture, op_tex
  • → 纹理采样操作通过 L1 的字节数

聚合后缀

每个计数器有多个子指标（在 CSV 列名中体现）：

二、GPU 硬件单元

计算单元

内存层次

显存访问层级与计数器关系

Shader 的纹理/内存请求不会直接到 DRAM，而是经过两级缓存逐层过滤：

Shader 请求 → L1/TEX Cache → L2 Cache (LTS) → DRAM

• L1 命中 → 直接返回数据，不产生下游流量
• L1 未命中 → 请求发往 L2
• L2 命中 → 数据返回 L1
• L2 未命中 → 请求发往 DRAM

对应计数器的数据流：

l1tex__t_bytes.sum              L1 总吞吐（全部请求）
  ├ l1tex__t_bytes_lookup_hit   L1 命中 → 到此为止
  └ l1tex__t_bytes_lookup_miss  L1 未命中 → 变成 L2 请求
        ↓
lts__t_bytes.sum                L2 总吞吐（含 L1 miss + PE/RASTER 等来源）
  └ lts__t_sectors_lookup_miss  L2 未命中 → 变成 DRAM 请求
        ↓
dram__bytes.sum                 实际 DRAM 流量

因此 DRAM 吞吐远小于 L1 吞吐，是经过两级缓存过滤后的结果。例如 L1 命中率 93% 意味着只有 7% 的请求需要访问 L2，再经 L2 过滤后到 DRAM 的更少。

L2 请求来源单元 (lts__t_sectors_srcunit_*)

L2 缓存接收来自多个硬件单元的请求，通过 lts__t_sectors_srcunit_*.sum 计数器可以区分来源：

• TEX — 纹理单元。SM 中 shader 的纹理采样（tex2D 等）和内存加载操作，L1 未命中后发往 L2。通常是 L2 请求的主要来源
• PE — Pixel Engine（像素引擎）。即 ROP 管线（PROP + ZROP + CROP），负责深度/模板测试和颜色混合，读写 Render Target 和 Depth Buffer 时产生 L2 请求
• RASTER — 光栅化器。ZCull 阶段读取层级深度缓冲 (Hi-Z) 做粗粒度深度剔除时产生的 L2 请求
• GCC — GPC Constant Cache。常量缓存和指令缓存的 L1.5 未命中后发往 L2，用于获取 shader 常量和指令数据

典型分布（以纹理密集型 drawcall 为例）：

TEX      67.6%   ← shader 纹理/内存访问（主体）
PE       29.4%   ← ROP 读写 RT/Depth Buffer
RASTER    2.6%   ← ZCull 读 Hi-Z
GCC       0.4%   ← 常量/指令缓存 miss

TEX 占比高说明 L2 压力主要来自纹理采样；PE 占比高说明 ROP 深度/颜色缓冲区读写量大（如高分辨率 MSAA 或大量 Late-Z）。

图形管线单元

三、SM 执行管线

SM 内部包含多条专用执行管线，不同类型的指令被路由到对应的管线执行：

XU 超越函数详细说明

XU 管线对应 SASS 指令 MUFU（Multi-Function Unit），是 SM 中吞吐量最低的管线之一。 当 XU/PS线程 值偏高时，需要重点排查以下函数的使用频率。

硬件直接支持的核心函数（1 次 MUFU 调用）：

编译器分解为多次 MUFU 调用的复合函数：

注意：pow 最容易被忽略——一次 pow() 调用会产生 2 次 XU 操作（LG2 + EX2）。

同样走 XU 管线的类型转换指令：

四、计数器详解（按分析模块分组）

4.1 GPU 时间与耗时

4.2 前端 (FE)

4.3 着色器线程启动

4.4 SM 指令执行

Warp 级指令（每条 warp 指令 = 最多 32 个线程同时执行的同一条指令）

重要：sm__inst_executed 系列是 warp 级别计数。当 .sum 后缀时，是所有 SM 的总和。1 条 warp 指令实际包含最多 32 个线程的执行。

线程级指令

warp 级 vs 线程级：sm__inst_executed 是 warp 级别（1 次计数 = 1 个 warp 发射 1 条指令）， smsp__thread_inst_executed 是线程级别（1 次计数 = 1 个线程执行 1 条指令）。 smsp__thread_inst_executed / sm__inst_executed 可算出每 warp 平均活跃线程数。

各着色器阶段指令

4.5 PS 线程淘汰（Kill Mask）

Kill Mask 概念：GPU 在像素着色器执行前后对像素进行淘汰。killmask_off 表示正常执行的线程（非预淘汰），killmask_on 表示已被 ZCull 等机制预先标记为淘汰的线程。

4.6 深度测试（Early-Z / Late-Z）

GPU 深度测试流水线的三个层级：

优化提示：Early-Z 比例越高越好。Late-Z 比例高说明 PS 使用了 discard()、写入了深度值或使用了 alpha test，导致 GPU 无法提前剔除不可见像素。

4.7 ZCull（粗粒度深度剔除）

4.8 VPC 几何处理（视口裁剪/剔除）

4.9 DRAM 显存带宽

4.10 L1/TEX 缓存

4.11 L2 缓存 (LTS)

4.12 GCC（全局常量/指令缓存）

4.13 SM Occupancy 与调度

4.14 SMSP Warp Stall（Warp 停顿原因）

Warp 停顿发生在 warp 因等待某种资源或依赖而无法发射指令时。理解停顿原因是性能优化的关键。

每个停顿指标的格式为 smsp__average_warps_issue_stalled_<原因>_per_issue_active，表示每个活跃的 issue slot 中平均有多少 warp 因该原因停顿。

记分板 (Scoreboard) 机制：每个 warp 有 6 个记分板，编译器用来追踪指令间的数据依赖关系。记分板记录哪些寄存器正在等待某条 in-flight 指令的写入。“Long” 表示离开 SM 的高延迟操作，“Short” 表示 SM 内部的低延迟操作。停顿出现在消费者 指令上，但根本原因在对应的 生产者指令。

五、常用计算公式

六、术语表

七、数值评估参考（怎样判断好坏）

以下给出各关键指标的参考阈值。实际最优值因场景而异（前向渲染 vs 延迟渲染、写实 vs 风格化、移动端 vs 桌面端）， 此处以桌面端典型游戏 drawcall 为基准，帮助快速判断是否存在明显问题。

7.1 缓存命中率

7.2 Occupancy（SM 占用率）

7.3 Warp 活跃线程 / 分支发散

7.4 Shader 复杂度特征

7.5 管线指令分布

7.6 深度测试效率

7.7 PS 有效输出率

7.8 VPC 几何效率

7.9 显存带宽

7.10 Warp Stall（停顿原因）

以下是停顿占比的参考判断：

怎么读停顿数据：先看 selected 占比——它代表 SM 在多少比例的周期中成功发射了指令。剩下的部分被各种停顿原因瓜分。找出占比最大的 1~2 个停顿原因，就是当前 drawcall 的主要瓶颈。

7.11 综合判断流程

1. 先看 GPU 耗时 → 这个 drawcall 值不值得优化？
   └ 单个 drawcall 占帧时间 >5% → 值得深入分析
   └ <0.1ms 的 drawcall 通常不是瓶颈

2. 看管线分布 → shader 在做什么？
   └ FMA 占主导 → 计算密集型
   └ TEX 占主导 → 纹理密集型
   └ LSU 占主导 → 内存密集型

3. 看 Warp Stall → 瓶颈在哪？
   └ long_scoreboard 主导 → 内存/纹理延迟瓶颈
   └ math_pipe_throttle 主导 → 计算吞吐瓶颈
   └ tex_throttle 主导 → 纹理单元饱和
   └ selected 占比很高 → SM 利用率好，可能瓶颈在别处 (ROP/Raster等)

4. 看缓存命中率 → 内存层次是否高效？
   └ L1 命中率低 → 访问模式不友好 (随机访问/stride过大)
   └ L2 命中率低 → working set 过大，带宽受限
   └ L2 TEX 命中率低 → 纹理太大/mipmap 不合适

5. 看深度测试 → 是否存在不必要的像素着色？
   └ Early-Z 比例低 → discard/写深度导致 Late-Z 回退
   └ ZCull 拒绝率低 → 渲染顺序不佳
   └ PS discard 率高 → alpha test 浪费

6. 看 PS 效率 → 像素着色器是否在做无用功？
   └ 有效输出率低 → helper lane、discard 浪费
   └ 活跃线程/warp 低 → 小三角形多，quad 浪费严重

本文档由 NvProfAnalyzer 自动生成，基于 NVIDIA Nsight Compute / Nsight Graphics / Nsight Perf SDK 官方文档整理。