Owner恢复验收 · 2026-10-26： 动态GPU Counter列为第11个恢复目标，当前仍candidate且未新增实时样本。历史“暂停”指示已被最新Owner目标覆盖；原始来源、实时持续性、物理含义未证明的边界保持。全指标恢复计划。

Dynamic GPU Counter（动态硬件 GPU 计数器）

作用域属性：[设备级 · 整机环境]（Device Scope ⓘ） 当前状态（2026-10-05）：candidate。现有正常产品通知路径仍缺 decoded data；独立来源探针的 flush 回复已取得可解原始计数块，但重复读取持续性、正常产品实时路径及物理精度尚未通过。控制通道、有数据块、连续性、精度分列。

1. 定义与业务价值

Dynamic GPU Counter 的目标是透传 Apple Silicon 芯片硬件级 GPU 计数器的原始值，理论上可用于比 Graphics gauge ⓘ 更细粒度的硬件级图形分析。2026-10-05 新来源取证已取得并解码 flush 二进制块；正常产品通知流的连续输出与物理单位仍待验证。当前只按 source-native-count 候选处理，不宣称物理利用率或实时精度已校准。

2. metricID / scope / unit / source

字段	值
metricID	ios.device.gpu.counter.source_native
scope	device
unit	source-native-count（未知具体物理含义，不猜单位）
source	dvt.instruments.gpu
sourceKey	dynamic-schema[counter]
definitionVersion ⓘ	gpu-counter-source-native.candidate.v2

取自当前 Registry ⓘ。

3. iOS 系统原理

Metal/GPU 硬件计数器是 Apple 私有的、按 SoC 型号变化的动态 schema——不同芯片、不同 iOS 版本暴露的计数器数量、名称、单位都可能不同，没有公开文档定义其含义。Perfowl 不对这些私有计数器的物理含义做任何猜测性命名。

4. 系统服务 / 通信通道 / 采集命令与实现

通道：com.apple.instruments.server.services.gpu（DTX ⓘ）。控制序列（MacApp/Sidecar/perfowl_collector_core/pmd3_deep_services.py::GPUCounterStream，Perfowl 自研控制封装层，基于 pymobiledevice3 DTX 内核）：

service.request_device_gpu_info()
  → 读取 min-collection-interval
service.configure_counters_counter_profile_interval_window_limit_tracing_pid_(
    counters=minimum, counterProfile=3, interval=1, windowLimit=0, tracingPID=-1
)
service.start_collecting_counters()
  → 数据到达
service.stop_collecting_counters()
service.flush_remaining_data()

解码由 Perfowl 自研的 GPUCounterDecoder（MacApp/Sidecar/perfowl_collector_core/gpu_counter.py）尝试完成，py-ios-device 仅作历史 schema 逆向研究参考，不是运行时依赖。

5. 原始字段与字段语义

• device-info 事件：request_device_gpu_info() 返回的设备 GPU 元信息（含 min-collection-interval）；
• schema-ready 事件：表示计数器 schema 已就绪；
• 数据行：理论上应为按 schema 解码出的计数器键值对，当前实测收到的实际消息是当前 decoder 不支持的 [int, int] 两整数 message shape，无法解码为有意义的计数器数据（详见第 11 节真机证据）。

6. 精确公式

x = u（absolute）；x = u - previous（delta且同schema/无reset）
value = float(x)，仅finite且int(value)==x；否则末行missing
Raw = 末行UInt64整数及差分整数（JSON原生整数），不做单位换算

由于当前 decoder 尚未能把真机收到的两整数消息形态解码为合法计数器行，这一公式目前在真机上没有产出过非空的已解码数据。

7. Clock / Window / Freshness

设计上采用 host receive monotonic 时钟做新鲜度判定：当前 sample 时间与最近一条**合法（decode_status=decoded）**数据行的时间差 > 10 秒，或时钟倒退，则置为 missing，不保持最后值无限有效；普通 heartbeat 消息不计入数据样本，也不刷新有效期。10 秒阈值来自已批准的 R0~R6 计划的初始合同，待真实协议/低频设备验证后可能调整，不宣称已对所有 SoC 完成校准。

8. Baseline / Reset / Discontinuity

schema 变更、明确无效数据或 reset 后清空当前显示窗口，不跨 schema 拼接旧值。当前值窗口只是展示层质量控制，不修改已保存的 source-native ⓘ 指标本身或差分公式。

9. Quality：valid / candidate / missing

• device-info / schema-ready：candidate（控制层事件，不是数据值）；
• 合法解码的计数器行（decode_status=decoded）：candidate；
• 未知 message shape（当前真机实测的主要情形）、schema 与 data 数量不匹配（schema key 数量 与 data row value 数量 必须严格匹配，否则整行 missing/degraded）：不解码、不猜值；
• 时间窗超时或时钟倒退：missing。

10. 合法 0 的条件

0 是合法的计数器值（如某计数器确实为 0），但当前真机测试中的核心问题不是"值为 0"，而是"decoded data row 数量为 0"——即根本没有解码出任何合法数据行，这与"计数器数值为 0"是完全不同的两件事，不得混淆。

G14A 动态源取证补充 · 2026-10-05

一次受控测试共1398条GPU来源事件：1条device-info、1396条unsupported-message、1条schema-ready；counterValues 全部为null。首个拒绝对象是长度2的整数列表；仅有schema/设备信息不代表已有计数数据，长度2也不证明存在被漏接的完整计数正文。保留原始证据，待通知/aux与配置机制审计；本指标未获得实时有效性或独立准确性验收。 受控测试与未关门清单。

11. 当前证据、校准与平台覆盖（如实披露，这是全站证据等级最低的指标之一）

多轮真机测试记录了同一个未关闭问题（内部编号 FTI-009 · GPU Counter data-row protocol）：

• 控制通道可达：device-info 与 schema-ready 均成功返回；
• 第二轮真机 Start 已将 GPU Counter 正确纳入 CapturePlan 后，共收到 1248 条 GPU raw event：1 条 device-info、1 条 schema-ready、其余 1246 条均为当前 decoder 不支持的 [int, int] 两整数 message shape；
• decoded data row = 0——没有一条被成功解码为合法计数器值；
• 团队明确冻结原则：未知的两整数消息不得被猜测性地解释为计数器数值，必须从原始 DTX dispatch/notification envelope 重新取证、核对 configureCounters:counterProfile:interval:windowLimit:tracingPID: 参数合同后才能推进 decoder；
• 第一轮测试中 Recording 中途添加 GPU Counter、Start 时未进入 CapturePlan 导致 gpu.counter.raw=0，这属于预期内的产品语义（未武装的数据源只在下一次 Session 生效，不动态修改当前 CapturePlan），与 FTI-009 是两个不同的问题。

如实结论：截至当前已整理的证据，Dynamic GPU Counter 在真机上尚未产出过一条可信的已解码计数器数据；控制层链路健康不等于数据层可用。任何声称该指标"可用于硬件级 Metal 纹理与显存吞吐分析"的表述都与现有证据矛盾，不得采信。

12. 如何分析：能得到什么结论，不能得到什么结论

能得到：目前仅能确认控制通道（configure/start/stop/flush）功能正常，可以证明"GPU Counter 服务本身可达"。

不能得到：当前不能从本指标获得任何可信的硬件计数器数值，不能用于任何形式的性能分析或诊断，直到 FTI-009 关闭并有真实 decoded data row 证据为止。

13. 常见误区

• 把"服务可达 / schema-ready"误当作"已经能读到计数器值"；
• 把未解码的原始消息当作已知计数器数值使用；
• 把本指标与 GPU Utilization（Graphics gauge）混淆——后者是已经稳定可用的独立 source。

14. Legacy / 历史实现

gpu-counter-source-native.candidate.v1 是历史实现；v2增加精确整数门和末行身份，不回写旧Session。正常产品通知链仍缺连续值；2026-10-05 新来源探针的独立 flush 正文已可解，维持 candidate 与未校准，不与旧 FTI-009 历史观测混用。

15. 版本历史与来源批次

本页由 site/knowledge/metrics/gpu-counter.md 拆分而来。

版本	日期	修订要点
v1（本页）	2026-09-18	从 gpu-counter.md 拆出，成为 Dynamic GPU Counter 独立 Canonical；补充 FTI-009 完整真机证据（1248 raw / 1246 未知 shape / decoded data row = 0），移除"深入分析硬件级 Metal 纹理与显存吞吐"等超出当前证据的表述。
v1 · 2026-10-05来源更新	2026-10-05	G20-R1/G21/G22保存原始flush正文，G23独立校验2798行一致；重复读取后续为空，正常产品实时路径/精度未提升；旧FTI-009历史保留。
证据更新（算法未改）	2026-10-05	G14A单轮来源及未校准边界，完整54项独立误差/正式五轮仍pending。
诊断修复（算法未改）	2026-10-05	G16保留首/尾真实位置及采样前合并元数据，GPU数值独立可信仍pending；采集伪代码纠正为当前真实命名参数。
配置传输修复（公式/默认未改）	2026-10-05	G18 reference全1sentinel显式有符号wire投影；真实MessageAux匹配与current字节保真，动态值和精度仍pending。

G15/G16 诊断范围补充 · 2026-10-05

G14A的schema在Start后1.060605454s收到，早于Stop，不支持“schema仅在停止后到达”的推断。原首/尾64条控制样本都滚动导致首部覆盖，已定位其取证缺陷；旧记录原件保留。本次修复只保留真正前64/末64，并在通知payload/aux合并之前记录有界结构元数据（前64通知、以后每64通知采样，前8顶层项/16种结构键）；未采aux与嵌套字节明确unknown，不保存正文。该诊断不改变默认配置、合并顺序、counter公式、质量或source-native候选边界，尚无新包真机counter值验收。

以上采集伪代码按实际命名参数校正；reference配置另为(0,3,0,-1,0xFFFFFFFF)，仅是独立实验假设，产品默认current不切换。公开客户端实现不构成Apple官方字段或本设备有效性的证明。详见正式方案与验证。

G17/G18 配置传输边界 · 2026-10-05

current真实60s来源探针602行中device-info1/schema1/二整数unsupported600、decoded data0；reference在本地编码时退出、0订阅，故不是两个设备配置均无值的对照结论。对照逻辑tracingPID=0xFFFFFFFF在pinned PInt32有符号INT32编码器溢出，现显式投影为-1，wire末四字节ffffffff；默认current五参数包字节不变。其它超界值不截断/取模，bool/float不强制转整数。configureWriteReturned仅代表本地发送调用返回，不代表设备ack。该修复关闭本地编码Bug，GPU物理含义/独立精度与54项五轮仍待验收。

G19新reference-only来源探针：完成=True，live data行=0，Stop尾段单列不补live连续率；实际设备写入/采样结果不证明计数公式或独立精度通过。旧G17本地失败继续保留，详细字段与资源见Canonical。

G19停止flush真实reply包含2303424B二进制正文；当前关闭路径未消费返回值。原探针仅留结构，正文未保存/未解码，故live0不等于设备完全无GPU数据，默认current配置与实时能力仍需另行取证。下一G20先取当前配置采集中一次有界flush正文并验证时间/scope/decoder，再定产品修复，不把Stop数据伪装live连续。

2026-10-05 来源协议更新（不替代产品连续性验收）

G20-R1 current采集中15s收到443808B/1541行；G21 current与G22 reference首5s分别145440B/505行、216576B/752行，两者15s再次读取与终止读取均空。G23逐行LE UInt64解析：2798行严格递增，声明行数/终点absolute及delta投影与现有decoder一致，实值精度丢失0；schema35字段另加领先timestamp。全部原sample-type=6，含义未证，原公式字符串不执行。

这是原始字节/解码一致性，不是物理GPU利用率精度或整窗持续性证明；Mach ticks未有本批GPU-specific转换证明，不直接换算连续秒数。G20原mixed回复拒绝partial保留。产品关闭时忽略flush返回的事实仍待修复，但直接周期flush假设未获持续性支持；下一单变量interval=0来源与自有呈现参考对照先取证再决定产品方案，禁止hold-last补齐有效率。完整字段/方法/资源及边界。

2026-10-05 G24–G27来源复核（算法未改）

G24-R1固定interval=0/无liveflush，终止原始1488096B/5167行且正常data通知0；G25固定windowLimit=1正常与终止正文0，独立自有Surface回调覆盖测量括号。呈现活动不证明GPU时轴或物理计数精度。两参数分别单变量，不将结果互相归因，不盲试其它数字、不缓存补槽；正常产品live路径尚未修好。 全54/独立误差/正式五轮100%仍待验收。完整方法、失败阶段与资源。

终止原始回复与实时数据分离 · 2026-10-05 G29

正在实施的G29正常Stop路径将Stop+一次flush置于共享400ms协作预算，保留queue中正常backlog，原500ms消费drain不变。成功native回复只作为gpu.counter.terminal.raw原始控制证据、terminal-buffer-not-live、counterValues=null保存；不是动态Counter公式输入，不更新实时freshness/连续性或GPU live census。来源在停止后交回缓冲，不等于测量窗口内实时收到数据。

Raw上限为native bytes总4MiB/容器8项/深度4/节点128/字符串64KiB；未知类型与超限整条拒绝、状态明确，失败/取消不补0或重试。Raw base64保存原字节，旁列byte段SHA与操作状态；完成状态表示Stop/flush调用完成，最终磁盘完整性仍以Raw封存与回放为证。当前为源码及E2验证阶段，实际安装b119未含此改动，完整回归1项50ms门失败，尚未打新包；真机正常路径与物理精度门仍开放；本页当前candidate状态不升级。方案与实现记录。

2026-10-05 G32精确整数投影合同（实现前入档）

已实施v2（E2通过，b120已签名公证覆盖安装E3）：UInt64原生整数x（absolute=u；delta=u−previous，warmup/reset无值）仅在finite(float(x))且int(float(x))==x时允许Double候选。末行任一counter损失则整行missing，Raw保留末行原生/差分整数、损失键与计数；末行全reset也不使用此前行。高于2^53但可精确表示的整数仍可保留，不以数值大小猜物理意义。所有被拒槽仍计入54项/五轮分母，missing不视为有效。实现/效率/整套回归与安装状态另列，旧设备数据是否触及边界unknown。完整合同。

版本补充：v2 · 2026-10-05，精确UInt64→Double往返门、末行任一损失整行missing、末行全reset不回退旧值、Raw原生整数留存。合成边界证明，不等于本设备物理校准；旧v1真机观察仍为历史。

G32内部包b120已实际含v2与G29终止Raw保全；63专项目标/1503完整Python/227 Swift（3skip）/五对效率通过。物理校准、GPU实时持续及全54正式五轮仍pending，0本批新设备Session；旧G29回归失败原因unknown，保留而不宣称已定位。

版本增量 · 2026-10-26：Owner曾暂停本项验收，随后同日最新指示恢复按序验收；算法、质量合同及历史来源数字不变，实时可用性仍未验证。