2、瓶颈识别方法：使用性能计数器、Roofline模型分析、Profiling工具介绍
好，咱们进入正题。上一章聊了内存带宽为什么是嵌入式GPU的命门，这一章就来讲讲——你怎么找到这个命门到底卡在哪。
说白了，瓶颈识别就是“找茬”。你得知道是计算单元在等数据，还是数据通道本身就不够宽。我个人习惯，先看性能计数器，再用Roofline模型画个图，最后用Profiling工具定点打击。三步走，基本不会漏。
2.1 性能计数器：硬件给你的“体检报告”
每个现代GPU都内置了一堆性能计数器。它们就像汽车的OBD接口，能告诉你发动机转速、油温、进气量。嗯，这里要注意——不同厂商的计数器名字千奇百怪，但核心指标就那么几个。
| 计数器名称 | 含义 | 我关注的点 |
|---|---|---|
| gpu_cycle | GPU核心时钟周期数 | 总时间基准 |
| gpu_inst_issued | 发射的指令数 | 看计算压力 |
| gpu_mem_read_transactions | 内存读取事务数 | 带宽消耗大户 |
| gpu_mem_write_transactions | 内存写入事务数 | 同样重要 |
| gpu_stall_imem | 指令缓存停顿周期 | 代码局部性差 |
| gpu_stall_dmem | 数据缓存停顿周期 | 内存带宽瓶颈的直接证据 |
我在项目中遇到过最典型的场景：一个图像处理管线，帧率死活上不去。一看gpu_stall_dmem占了总周期的70%以上。好家伙，计算单元大部分时间都在干等数据。这时候你优化计算逻辑没用，得从访存模式下手。
gpu_stall_dmem 占比。如果超过30%，基本可以断定是内存带宽瓶颈。如果低于10%，那问题大概率在计算或调度上。
2.2 Roofline模型：一张图看清瓶颈在哪
性能计数器告诉你“哪里堵”，Roofline模型告诉你“为什么堵”。这个模型其实很简单——横轴是计算强度（Operations/Byte），纵轴是性能（FLOPS）。
为什么会这样？因为任何计算任务，性能上限都由两条线决定：
- 天花板线：GPU的峰值计算能力（比如20 GFLOPS）
- 带宽线：内存带宽决定的斜率（比如10 GB/s）
你的任务落在哪个区域，就决定了瓶颈类型。
// 计算强度 = 总计算量 / 总数据移动量
// 比如一个矩阵乘法：
// 计算量：2 * N^3 (乘加操作)
// 数据量：3 * N^2 * 4 (float类型)
// 计算强度 ≈ (2*N) / 12
float compute_intensity = (2.0f * N * N * N) / (3.0f * N * N * sizeof(float));
printf("计算强度: %.2f Ops/Byte\n", compute_intensity);我记得有一次帮团队分析一个卷积层。计算强度算出来只有0.8 Ops/Byte，画在Roofline图上，明显落在带宽限制区。说白了，你GPU算得再快也没用，数据喂不进去。后来我们做了算子融合，把计算强度提到了4.2，性能直接翻倍。
- 计算强度 < 拐点值 → 带宽瓶颈（优化访存）
- 计算强度 > 拐点值 → 计算瓶颈（优化算法）
2.3 Profiling工具：定点打击的“手术刀”
性能计数器和Roofline模型帮你定位了方向，但具体是哪一行代码、哪个循环在吃带宽？这就需要Profiling工具上场了。
嵌入式GPU领域，我常用的工具就这几个：
| 工具 | 适用平台 | 我最常用的功能 |
|---|---|---|
| NVIDIA Nsight Systems | Jetson系列 | 时间线视图，看CPU/GPU交互 |
| ARM Streamline | Mali GPU | 内存带宽实时曲线 |
| Qualcomm Snapdragon Profiler | Adreno GPU | Shader执行统计 |
| 自定义计时器 | 所有平台 | 精确到微秒的kernel耗时 |
你想想看，Nsight Systems的时间线视图能让你一眼看出——GPU kernel在等CPU提交数据，还是CPU在等GPU算完。我曾经遇到一个坑：CPU端用cudaMemcpy同步拷贝，结果GPU空闲了40%的时间。改成异步流之后，吞吐量直接拉满。
2.4 实战：三步定位法
光说不练假把式。我总结了一套实战流程，你拿去就能用：
- 第一步：跑性能计数器
- 开启所有相关计数器
- 记录
gpu_stall_dmem占比 - 如果 > 30%，进入第二步
- 第二步：画Roofline模型
- 计算你的核心kernel的计算强度
- 对比拐点值
- 确认是带宽瓶颈还是计算瓶颈
- 第三步：Profiling定点
- 用工具找到最耗时的内存访问代码
- 检查是否有非合并访问、bank冲突
- 优化后重新跑，对比计数器变化
我个人习惯，每次优化完都会再看一眼gpu_stall_dmem。如果从70%降到了20%，说明方向对了。如果没变化，嗯，那可能你优化的不是真正的瓶颈。
下一章，我们会深入具体的内存访问模式优化。你先把这三板斧练熟，瓶颈识别准了，优化才能事半功倍。