外观
GPU 与图形硬件总览：Graphics Gauge / Dynamic Counter / Display 三者边界
先看结论
- Perfowl 目前有两个独立的 GPU 相关事实源：Instruments Graphics 服务提供的 Renderer/Tiler/Device Utilization（Renderer已完成ARM198五轮限定E4正式验收，保留无独立精度参考标记；Tiler/Device尚待专项验收），以及设备硬件 Dynamic GPU Counter（控制通道可达，但当前真机测试 decoded data row 恒为 0，不可用于分析）。
- GPU 利用率与 Display Presentation （FrameTime/FPS） 是不同 source、不同层次的事实，不能把 Display 层的呈现事实重新归到 GPU source，也不能反过来用 GPU 利用率直接解释 Display 呈现结果。
- 单个 GPU 利用率百分比不能直接解释成具体 shader、overdraw 或顶点数问题，只是缩小排查范围的候选方向。
图：三类信号来自不同 source；GPU 利用率高与 Display 掉帧只能做相关性对齐，不能互相替代。
0. 当前实现摘要
- Graphics gauge （
ios.foreground.gpu.renderer_utilization/tiler_utilization/device_utilization）：通过com.apple.instruments.server.services.graphics.opengl，pymobiledevice3 原生Graphics(provider)采集，foreground-device scope，已有多轮真机证据。 - Dynamic GPU Counter（
ios.device.gpu.counter.source_native）：通过com.apple.instruments.server.services.gpu，Perfowl 自研控制封装GPUCounterStream采集，device scope，控制通道可达但当前 decoded data row 恒为 0（FTI-009 未关闭）。
1. 这个领域到底观察什么
回答"当前前台图形管线的负荷分布在哪个阶段"（Graphics gauge），以及（理论上，尚未达成）"设备硬件计数器的细粒度数值是什么"（Dynamic Counter）。不直接回答"是哪一帧、哪个 draw call"。
2. iOS 系统原理
GPU 是全机共享硬件；当前 Perfowl 可用的系统接口不能提供经验证的“按目标 PID 精确切分 GPU 使用率”语义。Instruments 通过两条不同的私有服务分别暴露"图形管线阶段利用率"（Graphics）和"硬件计数器动态 schema"（GPU service）——两者数据结构、精度、稳定性完全不同。
3. 本领域指标地图
| 指标 | metricID | scope | 回答什么问题 |
|---|---|---|---|
| GPU Utilization | ios.foreground.gpu.*_utilization | foreground-device | 图形管线负荷在 Renderer/Tiler/Device 三阶段的分布 |
| Dynamic GPU Counter | ios.device.gpu.counter.source_native | device | （目标，尚未达成）硬件级计数器细粒度数值 |
4. Perfowl 当前怎样取得这些事实
Graphics gauge 直接透传 Instruments 私有服务字段；Dynamic Counter 通过 requestDeviceGPUInfo → configureCounters → startCollectingCounters 控制序列尝试获取硬件计数器数据行，当前解码器无法识别真机返回的两整数消息形态，详见 GPU 采集技术演进与实验。
5. Scope / Identity / Runtime Condition
Graphics gauge 是 foreground-device——只在目标 App 前台时有效，退后台立即置 missing；Dynamic Counter 是 device——不做单进程过滤，是整机硬件计数器。
6. 指标应该怎样组合阅读
排查卡顿时，先看 Display 层的 FrameTime/FPS 确认是否真的掉帧 → 若怀疑 GPU 瓶颈，看 Graphics gauge 三个维度的分布 → 需要更细粒度硬件证据时（当前不可用，等待 Dynamic Counter 门禁关闭）。不要跳过 Display 层证据直接用 GPU 利用率下结论。
7. 常见异常形态：观察 → 候选原因 → 交叉验证 → 不能确认
| 观察 | 候选原因 | 下一步验证 | 不能确认的结论 |
|---|---|---|---|
| Renderer 极高，Tiler 低位 | 过度绘制、毛玻璃/透明图层堆叠等候选方向 | Xcode GPU Frame Debugger 检查 Overdraw | 不能仅凭利用率确诊具体是哪一层 |
| Tiler 极高，Renderer 中低位 | 几何顶点过多、缺乏 LOD 等候选方向 | 检查 3D 模型面数、视锥剔除 | 不能仅凭利用率确诊具体模型 |
| Device GPU 高但 FPS 正常 | 硬件负荷高但仍在预算内 | 结合 FrameTime 确认是否真的接近 VSync 上限 | 不能因为利用率高就断言"必定掉帧" |
| Device GPU 低但 FPS 很低 | CPU-Bound：主线程阻塞导致 GPU 饥饿等待 | 检查 APP CPU、线程状态 | 不能不看 CPU 就直接归咎 GPU |
8. 连续性、质量、missing / 0 / warmup
Graphics gauge：前台稳态 candidate，退后台 missing（not-foreground），不补 0。Dynamic Counter：device-info/schema-ready 为控制层事件（candidate），未解码的数据消息保持 missing，不猜值。
9. 当前证据与平台覆盖
Graphics gauge 有多轮真机 E2/E4 混合证据；Dynamic Counter 目前没有任何一条真机 decoded data row 的成功证据（FTI-009），是全站证据等级最低、门禁最明确的指标之一。
10. 常见误区
- 把 Graphics gauge 和 Dynamic Counter 当作同一个数据源的两种展示；
- 把 Display Presentation 的呈现事实重新归到 GPU source（Display FrameTime 有自己独立的 ActivityTrace 事实源，详见 Display Performance 总览）；
- 认为 Dynamic Counter 服务"可达"就等于"可以读到数值"。
11. 指标 Canonical 与技术演进入口
12. 继续阅读
版本历史 · 2026-10-21
Renderer ARM198新a06完整五轮正式通过，33/66；本页不将Renderer结论外推到Tiler/Device或独立精度。结果。