尧图网站建设 
Perfetto GPU 计算内核分析用 NVIDIA Compute Workload Analysis 找出饱和流水线与指令配比瓶颈【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto本篇指南基于 Perfetto 仓库中的 AI Skill 工作流文档讲解如何对一个 compute-bound 的 GPU 计算内核做指令吞吐与流水线利用率提取从而回答 GPU 调优中的关键问题到底是哪条执行流水线pipe先跑满指令配比instruction mix失衡点在哪里对应的优化杠杆是什么。读完后你可以直接在 Perfetto trace processor 中运行现成的 SQL 提取脚本读懂sm_busy_pct、ipc_active与alu/fma/fp16/fp32/fp64/tensor各列的含义并据此做出精度降级、指令配比调整或算法改动的决策。该文档位于 Perfetto 的 AI Skill 工作流体系内ai/skills/perfetto/workflows/gpu/compute/nvidia/compute_workload_analysis.md。它本身是一个厂商提取层vendor extraction通用的解释规则在上层的 compute_workload_analysis.md而整个 GPU 计算内核分析的分诊流程由 kernel_analysis.md 编排。这个工作流在整个 GPU 计算分析中处于什么位置Perfetto 的 GPU 计算内核分析采用四个透镜四个 Phase-2 工作流的分解方法Speed of Light、Occupancy、Compute Workload Analysis、Launch Statistics。Compute Workload Analysis 这一环的定位是前置条件先用 Speed of Light 判定内核确实是 compute-bound计算单元吞吐接近峰值而内存吞吐更低。只有在这个分支上哪条 pipe 饱和了才有意义如果 Speed of Light 显示的是 memory-bound 或双低latency/occupancy-bound应分别去看 speed_of_light.md 或 occupancy.md 指向的方向。解决的问题compute-bound 不是终点。指令发射吞吐和逐流水线利用率能揭示瓶颈究竟是 tensor 单元、FP32 单元还是整数/地址运算从而决定优化杠杆。输出形态每个 compute kernel 一行按执行时长降序排列longest first便于直接锁定热点内核。运行提取命令、前置条件与输出列按照文档给出的命令将 SQL 脚本交给 trace processor 执行$SKILL_ROOT在本仓库中对应 ai/skills/perfetto 目录SESSION为已加载 trace 的会话trace_processor query --remote SESSION \ --query-file ai/skills/perfetto/workflows/gpu/compute/nvidia/scripts/compute_workload_analysis.sql脚本文件为 ai/skills/perfetto/workflows/gpu/compute/nvidia/scripts/compute_workload_analysis.sql无参数、作用于整条 trace。输出的显示标签到 NVIDIA 计数器的映射如下完整继承原文档的映射表Display label (generic)ColumnNVIDIA counterCompute-unit busysm_busy_pctsm__instruction_throughput.avg.pct_of_peak_sustained_activeExecuted IPCipc_activesm__inst_executed.avg.per_cycle_activePipeline utilizationalu_pct,fma_pct,fp16_pct,fp32_pct,fp64_pct,tensor_pctsm__pipe_x_cycles_active.avg.pct_of_peak_sustained_active三个关键指标的定义来自通用解释层文档Compute-unit busysm_busy_pct——指令发射吞吐占峰值的百分比Executed IPCipc_active——每个活跃周期执行指令数Per-pipeline utilization——每条执行流水线占峰值的百分比。流水线集合是厂商特定的NVIDIA 上这六条 pipe 就是 SM 的执行单元ALU、FMA、FP16、FP32、FP64、Tensor。输入数据的前置条件脚本能出结果需要 trace 同时满足以下条件均可从脚本与 kernel_analysis.md 的 Reference 一节确认存在 compute kernelgpu_slice.render_stage_category 2COMPUTE 渲染阶段类别且dur 0。若同目录的kernels_summary.sql查不到任何行说明 trace 里没有 compute dispatch该工作流不适用存在 COMPUTE 计数器组所有值来自 COMPUTE 组的 GPU 计数器即gpu_counter_group.group_id 6GpuCounterGroup枚举的 COMPUTE 值。这些计数器需要由 NVIDIA 侧的 GPU producer 在采集时发出——如何配置 GPU 计数器采集gpu.counters数据源、counter_names/counter_ids、GPGPU 场景的 instrumented sampling、多 GPU 的gpu_id/ugpu区分见 docs/data-sources/gpu.mdugpu 对齐计数器轨道必须按ugpu与内核所在 GPU 匹配见下文 SQL 解析。深入 SQL 实现内核窗口与计数器如何关联完整阅读 compute_workload_analysis.sql其结构分三步第一步枚举 compute kernel_kernels临时表CREATE PERFETTO TABLE _kernels AS SELECT s.id, s.ts, s.dur, ROW_NUMBER() OVER (ORDER BY s.ts) AS launch_id, EXTRACT_ARG(t.dimension_arg_set_id, ugpu) AS ugpu, COALESCE( EXTRACT_ARG(s.arg_set_id, kernel_demangled_name), EXTRACT_ARG(s.arg_set_id, kernel_name), s.name ) AS kernel FROM gpu_slice AS s JOIN gpu_track AS t ON s.track_id t.id WHERE s.render_stage_category 2 AND s.dur 0;要点launch_id按启动时间戳排序生成与kernels_summary.sql的id一致因此同一内核可以在多个 Phase-2 报表间按id对齐内核名优先取 demangled 名回退到 mangled 名再回退到 slice 名ugpu来自 GPU track 的维度参数是后续计数器关联的键。第二步在内核窗口内对计数器取平均_kernel_counters临时表CREATE PERFETTO TABLE _kernel_counters AS SELECT k.id AS kernel_id, ct.name AS counter_name, AVG(c.value) AS avg_v FROM _kernels AS k JOIN gpu_counter_group AS g ON g.group_id 6 JOIN gpu_counter_track AS ct ON ct.id g.track_id AND ct.ugpu k.ugpu JOIN counter AS c ON c.track_id ct.id AND c.ts k.ts AND c.ts k.ts k.dur GROUP BY k.id, ct.name;这里有两个实现细节值得注意聚合方式是 AVG 而非 SUM。脚本头部注释明确说明本提取涉及的全部是速率/百分比类指标rate/percentage metrics所以窗口内取平均这与 speed_of_light.sql 中吞吐百分比用 AVG、周期计数与时长用 SUM的约定一致ct.ugpu k.ugpu的按 GPU 匹配保证多 GPU 场景下不会把别的卡上的计数器算进来时间条件c.ts k.ts AND c.ts k.ts k.dur则把稀疏的计数器采样裁剪到该内核的活跃窗口。第三步透视为每内核一行最终 SELECT最终查询对_kernel_counters按counter_name做CASE ... WHEN透视把长表内核 × 计数器名 → 平均值压成宽表sm__inst_executed.avg.per_cycle_active映射为ipc_active保留 2 位小数sm__instruction_throughput...映射为sm_busy_pct六条 pipe 的sm__pipe_x_cycles_active.avg.pct_of_peak_sustained_active分别映射为alu_pct/fma_pct/fp16_pct/fp32_pct/fp64_pct/tensor_pct各保留 1 位小数。通过LEFT JOIN保证即使某内核窗口内缺少某个计数器行仍会输出对应列为 NULL最后ORDER BY k.dur DESC让最长的内核排在最前。解读结果哪条 pipe 是瓶颈杠杆在哪里NVIDIA 上的计算单元是SMper-pipe 列就是 SM 的执行单元利用率。最高的一条 pipe 就是瓶颈候选而杠杆取决于它是哪条 pipe完整继承原文档的决策表tensor_pct高→ 已经走 tensor-core / 矩阵路径对 matmul 类工作是好事。此时的收益不来自改变指令配比而需要更大的 tile 或换算法fma_pct/fp32_pct高→ FP32 数学成为瓶颈若算法可容忍考虑降精度到 fp16 / bf16。注意文档特别指出bf16 的工作会体现在 fp16 / tensor pipe 上——这组计数器中没有专门的 bf16 cycles-active 计数器读表时不要找bf16_pctfp64_pct高→ 双精度代价昂贵在精度允许处降到 fp32alu_pct高→ 整数/地址运算受限减少索引算术或预先计算。一个重要的语义澄清同样继承自原文档这些是 pipe 的cycles-active计数器即该流水线处于活跃状态的周期占比是饱和度信号与之配对的sm__inst_executed_pipe_*每条 pipe 执行的指令数计数器不在本提取的范围内。通用解释层的三条判读规则NVIDIA 提取层之上的通用文档 compute_workload_analysis.md 给出了厂商中立的判读规则适用于把上述列读成结论单条 pipe 接近峰值、其余很低→ 该 pipe 就是瓶颈。杠杆是把工作从它上面移走能换更便宜的精度/指令配比就换或改用对该 pipe 需求更少的算法sm_busy_pct高但没有单条 pipe 接近峰值→ issue-bound / mixed单元忙着发射但工作分散在各条 pipe 上限制在指令发射本身。杠杆是减少指令数算法层面或提升 ILPsm_busy_pct低且所有 pipe 都低→ 其实不是 compute-bound。内核在 stall是内存或延迟受限——此时应回到 Speed of Light / Occupancy 视图找杠杆而不是继续看本表。此外精度 pipe 之间的失衡两条精度路径都处于中等利用率可能意味着内核混用了精度统一收敛到最便宜的够用精度可以释放发射槽位。实操要点与适用边界先分诊后深挖按 kernel_analysis.md 的 Phase 1先跑kernels_summary.sql锁定热点内核的id再用 Phase 2 各脚本围绕该id对齐读数本脚本的id列即 launch order与汇总表一致对比基线是逐行 diff由于每个脚本都是每内核一行比较两个内核改前/改后或两个变体就是相同脚本下两行之间的逐列对比厂商边界通用文档明确目前只有 NVIDIA 拥有完整的这条 Speed-of-Light / 流水线计数器链其他厂商需使用其各自暴露的指令吞吐 / IPC 指标本脚本中的计数器名sm__pipe_*等不适用于非 NVIDIA 硬件数值阈值是经验值Speed of Light 文档中提到 high ≈ ≥ 60% of peak 之类的切分是规则性经验rule of thumb并非厂商或插件定义的硬阈值解读时结合绝对水位与相对比较UI 侧交叉验证Perfetto UI 自带的com.meta.GpuCompute插件在选择 compute slice 时会展示 Summary / Details 页其中 Details 包含 Speed-of-Light、Launch Statistics、Occupancy、Compute Workload Analysis四个小节并支持双内核基线对比见 docs/data-sources/gpu.md 的 UI plugins 一节可与本脚本的 SQL 输出互相印证。小结本文围绕 Perfetto AI Skill 中的 NVIDIA Compute Workload Analysis 提取层展开它以gpu_counter_group.group_id 6COMPUTE 组的计数器为源按内核窗口取平均、按ugpu对齐把sm__instruction_throughput、sm__inst_executed.avg.per_cycle_active与六条sm__pipe_*_cycles_active计数器透视成每内核一行。结合最高 pipe 即瓶颈候选的杠杆决策表和通用层的三条判读规则可以在确认内核 compute-bound 之后精确回答饱和的是哪条流水线、指令配比怎么调这一 GPU 调优的核心问题。【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Perfetto GPU 计算内核分析：用 NVIDIA Compute Workload Analysis 找出饱和流水线与指令配比瓶颈
Perfetto GPU 计算内核分析用 NVIDIA Compute Workload Analysis 找出饱和流水线与指令配比瓶颈【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto本篇指南基于 Perfetto 仓库中的 AI Skill 工作流文档讲解如何对一个 compute-bound 的 GPU 计算内核做指令吞吐与流水线利用率提取从而回答 GPU 调优中的关键问题到底是哪条执行流水线pipe先跑满指令配比instruction mix失衡点在哪里对应的优化杠杆是什么。读完后你可以直接在 Perfetto trace processor 中运行现成的 SQL 提取脚本读懂sm_busy_pct、ipc_active与alu/fma/fp16/fp32/fp64/tensor各列的含义并据此做出精度降级、指令配比调整或算法改动的决策。该文档位于 Perfetto 的 AI Skill 工作流体系内ai/skills/perfetto/workflows/gpu/compute/nvidia/compute_workload_analysis.md。它本身是一个厂商提取层vendor extraction通用的解释规则在上层的 compute_workload_analysis.md而整个 GPU 计算内核分析的分诊流程由 kernel_analysis.md 编排。这个工作流在整个 GPU 计算分析中处于什么位置Perfetto 的 GPU 计算内核分析采用四个透镜四个 Phase-2 工作流的分解方法Speed of Light、Occupancy、Compute Workload Analysis、Launch Statistics。Compute Workload Analysis 这一环的定位是前置条件先用 Speed of Light 判定内核确实是 compute-bound计算单元吞吐接近峰值而内存吞吐更低。只有在这个分支上哪条 pipe 饱和了才有意义如果 Speed of Light 显示的是 memory-bound 或双低latency/occupancy-bound应分别去看 speed_of_light.md 或 occupancy.md 指向的方向。解决的问题compute-bound 不是终点。指令发射吞吐和逐流水线利用率能揭示瓶颈究竟是 tensor 单元、FP32 单元还是整数/地址运算从而决定优化杠杆。输出形态每个 compute kernel 一行按执行时长降序排列longest first便于直接锁定热点内核。运行提取命令、前置条件与输出列按照文档给出的命令将 SQL 脚本交给 trace processor 执行$SKILL_ROOT在本仓库中对应 ai/skills/perfetto 目录SESSION为已加载 trace 的会话trace_processor query --remote SESSION \ --query-file ai/skills/perfetto/workflows/gpu/compute/nvidia/scripts/compute_workload_analysis.sql脚本文件为 ai/skills/perfetto/workflows/gpu/compute/nvidia/scripts/compute_workload_analysis.sql无参数、作用于整条 trace。输出的显示标签到 NVIDIA 计数器的映射如下完整继承原文档的映射表Display label (generic)ColumnNVIDIA counterCompute-unit busysm_busy_pctsm__instruction_throughput.avg.pct_of_peak_sustained_activeExecuted IPCipc_activesm__inst_executed.avg.per_cycle_activePipeline utilizationalu_pct,fma_pct,fp16_pct,fp32_pct,fp64_pct,tensor_pctsm__pipe_x_cycles_active.avg.pct_of_peak_sustained_active三个关键指标的定义来自通用解释层文档Compute-unit busysm_busy_pct——指令发射吞吐占峰值的百分比Executed IPCipc_active——每个活跃周期执行指令数Per-pipeline utilization——每条执行流水线占峰值的百分比。流水线集合是厂商特定的NVIDIA 上这六条 pipe 就是 SM 的执行单元ALU、FMA、FP16、FP32、FP64、Tensor。输入数据的前置条件脚本能出结果需要 trace 同时满足以下条件均可从脚本与 kernel_analysis.md 的 Reference 一节确认存在 compute kernelgpu_slice.render_stage_category 2COMPUTE 渲染阶段类别且dur 0。若同目录的kernels_summary.sql查不到任何行说明 trace 里没有 compute dispatch该工作流不适用存在 COMPUTE 计数器组所有值来自 COMPUTE 组的 GPU 计数器即gpu_counter_group.group_id 6GpuCounterGroup枚举的 COMPUTE 值。这些计数器需要由 NVIDIA 侧的 GPU producer 在采集时发出——如何配置 GPU 计数器采集gpu.counters数据源、counter_names/counter_ids、GPGPU 场景的 instrumented sampling、多 GPU 的gpu_id/ugpu区分见 docs/data-sources/gpu.mdugpu 对齐计数器轨道必须按ugpu与内核所在 GPU 匹配见下文 SQL 解析。深入 SQL 实现内核窗口与计数器如何关联完整阅读 compute_workload_analysis.sql其结构分三步第一步枚举 compute kernel_kernels临时表CREATE PERFETTO TABLE _kernels AS SELECT s.id, s.ts, s.dur, ROW_NUMBER() OVER (ORDER BY s.ts) AS launch_id, EXTRACT_ARG(t.dimension_arg_set_id, ugpu) AS ugpu, COALESCE( EXTRACT_ARG(s.arg_set_id, kernel_demangled_name), EXTRACT_ARG(s.arg_set_id, kernel_name), s.name ) AS kernel FROM gpu_slice AS s JOIN gpu_track AS t ON s.track_id t.id WHERE s.render_stage_category 2 AND s.dur 0;要点launch_id按启动时间戳排序生成与kernels_summary.sql的id一致因此同一内核可以在多个 Phase-2 报表间按id对齐内核名优先取 demangled 名回退到 mangled 名再回退到 slice 名ugpu来自 GPU track 的维度参数是后续计数器关联的键。第二步在内核窗口内对计数器取平均_kernel_counters临时表CREATE PERFETTO TABLE _kernel_counters AS SELECT k.id AS kernel_id, ct.name AS counter_name, AVG(c.value) AS avg_v FROM _kernels AS k JOIN gpu_counter_group AS g ON g.group_id 6 JOIN gpu_counter_track AS ct ON ct.id g.track_id AND ct.ugpu k.ugpu JOIN counter AS c ON c.track_id ct.id AND c.ts k.ts AND c.ts k.ts k.dur GROUP BY k.id, ct.name;这里有两个实现细节值得注意聚合方式是 AVG 而非 SUM。脚本头部注释明确说明本提取涉及的全部是速率/百分比类指标rate/percentage metrics所以窗口内取平均这与 speed_of_light.sql 中吞吐百分比用 AVG、周期计数与时长用 SUM的约定一致ct.ugpu k.ugpu的按 GPU 匹配保证多 GPU 场景下不会把别的卡上的计数器算进来时间条件c.ts k.ts AND c.ts k.ts k.dur则把稀疏的计数器采样裁剪到该内核的活跃窗口。第三步透视为每内核一行最终 SELECT最终查询对_kernel_counters按counter_name做CASE ... WHEN透视把长表内核 × 计数器名 → 平均值压成宽表sm__inst_executed.avg.per_cycle_active映射为ipc_active保留 2 位小数sm__instruction_throughput...映射为sm_busy_pct六条 pipe 的sm__pipe_x_cycles_active.avg.pct_of_peak_sustained_active分别映射为alu_pct/fma_pct/fp16_pct/fp32_pct/fp64_pct/tensor_pct各保留 1 位小数。通过LEFT JOIN保证即使某内核窗口内缺少某个计数器行仍会输出对应列为 NULL最后ORDER BY k.dur DESC让最长的内核排在最前。解读结果哪条 pipe 是瓶颈杠杆在哪里NVIDIA 上的计算单元是SMper-pipe 列就是 SM 的执行单元利用率。最高的一条 pipe 就是瓶颈候选而杠杆取决于它是哪条 pipe完整继承原文档的决策表tensor_pct高→ 已经走 tensor-core / 矩阵路径对 matmul 类工作是好事。此时的收益不来自改变指令配比而需要更大的 tile 或换算法fma_pct/fp32_pct高→ FP32 数学成为瓶颈若算法可容忍考虑降精度到 fp16 / bf16。注意文档特别指出bf16 的工作会体现在 fp16 / tensor pipe 上——这组计数器中没有专门的 bf16 cycles-active 计数器读表时不要找bf16_pctfp64_pct高→ 双精度代价昂贵在精度允许处降到 fp32alu_pct高→ 整数/地址运算受限减少索引算术或预先计算。一个重要的语义澄清同样继承自原文档这些是 pipe 的cycles-active计数器即该流水线处于活跃状态的周期占比是饱和度信号与之配对的sm__inst_executed_pipe_*每条 pipe 执行的指令数计数器不在本提取的范围内。通用解释层的三条判读规则NVIDIA 提取层之上的通用文档 compute_workload_analysis.md 给出了厂商中立的判读规则适用于把上述列读成结论单条 pipe 接近峰值、其余很低→ 该 pipe 就是瓶颈。杠杆是把工作从它上面移走能换更便宜的精度/指令配比就换或改用对该 pipe 需求更少的算法sm_busy_pct高但没有单条 pipe 接近峰值→ issue-bound / mixed单元忙着发射但工作分散在各条 pipe 上限制在指令发射本身。杠杆是减少指令数算法层面或提升 ILPsm_busy_pct低且所有 pipe 都低→ 其实不是 compute-bound。内核在 stall是内存或延迟受限——此时应回到 Speed of Light / Occupancy 视图找杠杆而不是继续看本表。此外精度 pipe 之间的失衡两条精度路径都处于中等利用率可能意味着内核混用了精度统一收敛到最便宜的够用精度可以释放发射槽位。实操要点与适用边界先分诊后深挖按 kernel_analysis.md 的 Phase 1先跑kernels_summary.sql锁定热点内核的id再用 Phase 2 各脚本围绕该id对齐读数本脚本的id列即 launch order与汇总表一致对比基线是逐行 diff由于每个脚本都是每内核一行比较两个内核改前/改后或两个变体就是相同脚本下两行之间的逐列对比厂商边界通用文档明确目前只有 NVIDIA 拥有完整的这条 Speed-of-Light / 流水线计数器链其他厂商需使用其各自暴露的指令吞吐 / IPC 指标本脚本中的计数器名sm__pipe_*等不适用于非 NVIDIA 硬件数值阈值是经验值Speed of Light 文档中提到 high ≈ ≥ 60% of peak 之类的切分是规则性经验rule of thumb并非厂商或插件定义的硬阈值解读时结合绝对水位与相对比较UI 侧交叉验证Perfetto UI 自带的com.meta.GpuCompute插件在选择 compute slice 时会展示 Summary / Details 页其中 Details 包含 Speed-of-Light、Launch Statistics、Occupancy、Compute Workload Analysis四个小节并支持双内核基线对比见 docs/data-sources/gpu.md 的 UI plugins 一节可与本脚本的 SQL 输出互相印证。小结本文围绕 Perfetto AI Skill 中的 NVIDIA Compute Workload Analysis 提取层展开它以gpu_counter_group.group_id 6COMPUTE 组的计数器为源按内核窗口取平均、按ugpu对齐把sm__instruction_throughput、sm__inst_executed.avg.per_cycle_active与六条sm__pipe_*_cycles_active计数器透视成每内核一行。结合最高 pipe 即瓶颈候选的杠杆决策表和通用层的三条判读规则可以在确认内核 compute-bound 之后精确回答饱和的是哪条流水线、指令配比怎么调这一 GPU 调优的核心问题。【免费下载链接】perfettoProduction-grade client-side tracing, profiling, and analysis for complex software systems.项目地址: https://gitcode.com/GitHub_Trending/pe/perfetto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考