JINHU
下面给你一份 非常专业、适用于 PowerVR (RGX) 驱动/固件调试语境 的对比表，涵盖：
-
Native fence
-
Foreign fence
-
Update fence
并严格对应 PVRSRV Sync / UFO / FWCtx / CCB 的实际实现与常见问题（包括你 dump 中遇到的 <Invalid UFO update> 情况）。
✅ Native fence / Foreign fence / Update fence — 专业对比表
| 项目 | Native Fence | Foreign Fence | Update Fence |
|---|---|---|---|
| 定义（PVRSRV 官方语义） | 当前 FWCtx / 当前 CCB 自己产生的 fence （本地生产，本地消费） | 由外部生产者（其他 FWCtx / 其他进程 / CPU-side）生成，但被本 FWCtx 所依赖的 fence | 一个需要本 FWCtx 在完成任务后主动写回的 UFO（更新动作由本 context 生产） |
| 生产者（Producer）是谁？ | 本 FWCtx（例如 TA/3D/CDM/TO 自己提交的命令） | 其他进程 / 其他 FWCtx / CPU / UM 层提交者 | 本 FWCtx（GPU 中某个任务完成后固件写 update） |
| 消费者（Walter）是谁？ | 本 FWCtx 本身 | 本 FWCtx（等待外部 sync 完成） | 其他 FWCtx 或 UM/CPU（等待本 context 的任务完成） |
| 更新由谁完成？ | 本 FWCtx 完成后固件自动写（firmware-controlled） | 外部 producer（UM/CPU 或其他 FWCtx）必须写更新 | 本 FWCtx 完成过程由固件写入 sync update |
| 是否跨 Context？ | 否（本地同步） | 是（跨 context/跨进程） | 可能（通常跨 context，用于同步多个队列） |
| 固件是否信任其格式？ | 100% 信任（因为本 context 产生） | 需要验证（很容易出现 <Invalid UFO update>） | 100% 信任（固件自己写） |
| 典型使用场景 | 多段 GPU pipeline 内部同步（TA → 3D） | Xorg/游戏需要等待别的队列完成 | GPU 作为生产者向 UM 提供完成信号 |
| 在 debug_dump 中的表现 | Waiting FENCE (native) | Waiting FENCE (foreign) | Waiting UPDATE 、Waiting UPDATE_FENCE |
| 异常风险 | 较低 | 最高：外部 producer 更新失败、格式不对、UM/KM 版本不匹配 | 中等：固件无法写出更新（队列阻塞） |
| 常见错误类型 | Pipeline stall | Invalid UFO update（你当前 dump 最大问题） | Update 超时导致后续任务挂起 |
| 对应的 MMU 相关性 | 小 | 小或中：若 foreign producer 写到错误地址 | 小：固件写 update 出错较少出现 MMU fault |
| 调试难度 | 最低 | 最高（涉及多个 client / 多个 FWCtx） | 中等 |
📌 三者的本质关系（一句话理解）
Native fence
- 是同一个 context 内部“自己等自己”，用于 GPU pipeline 内的同步（例如 TA 完成后才能开始 3D）。
Foreign fence
-
是“等别人”。当前 FWCtx 等另一个上下文/进程/CPU 写出更新。
-
如果别人不写或写错 → Invalid UFO update → GPU 卡住。
Update fence
- 是“别人等我”。当前 FWCtx 完成任务后写一个更新，告知别人它已经完成。
🔥 Why Foreign Fence 最容易出问题？
因为 foreign fence 的 update：
-
来自别的 FWCtx
-
来自外部进程
-
来自用户态驱动（UM）
-
或来自 CPU
固件不是生产者，只是等待者（consumer）→ 它只能接收，不负责生成 → 任何格式/协议问题都会被标为 Invalid。
在 debug_dump 中反复出现：
Waiting FENCE (foreign)
\--- <Invalid UFO update>这是典型：
UM/KM 驱动版本 mismatch → UFO 格式/字段不一致 → foreign fence update 被固件视为无效 → 多个 context 全部挂起。
📘 更专业的延伸对比（适合你这种在看源码和固件的开发者）
| 深度属性 | Native Fence | Foreign Fence | Update Fence |
|---|---|---|---|
| 固件与用户态协议依赖 | 最少 | 最多（需要 match sync protocol） | 中等 |
| 依赖 Sync Prim / Sync Checkpoint? | 是 | 是（且多为多方依赖） | 是 |
| 固件是否需要 validate? | 不需要 | 要验证 (ID/addr/value/type) | 不需要 |
| 可能出现的错误代码 | pipeline hang | InvalidSyncPrim, SynclotSignalled | UpdateTimeout |
| 典型 CCD 状态 | TA Waiting | Waiting FENCE (foreign) | Waiting UPDATE |
| 对应的 SyncCP activity | 少量 | 大量（你 dump 里 InUse=214） | 若阻塞则逐渐增加 |
📌 “Invalid UFO update” 与 foreign fence 的特定关系
Invalid UFO update 几乎只出现在 foreign fence，因为 foreign fence 的 update 来自外部，固件必须验证：
-
地址是否匹配
-
update count 是否按序
-
内核态/用户态是否按协议写入
-
sync primitive 是否合法
-
update 操作是否落在 GPU 可访问的域
UM/KM mismatch 会让固件看到“结构字段错位”，因此所有 foreign fence 均报 invalid。
🎯 最实用的判断规则（做调试时即可用）
| 如果你在 debug_dump 看到 | 说明 |
|---|---|
| Waiting FENCE (native) 长期不动 | GPU pipeline 自己内部死锁，通常是 driver bug |
| Waiting FENCE (foreign) + <Invalid UFO update> | UM/KM 不匹配 / 外部 producer 没按协议写 update（你当前情况） |
| Waiting UPDATE 长期卡住 | 当前 FWCtx 无法写出 update（CB 资源枯竭等） |
单一 FWCtx（单 context）内部细节（native vs foreign vs update）
sequenceDiagram
autonumber
participant App as UM Client
participant KM as Kernel Module
participant FW as RGX Firmware (FWCtx)
participant UFO as Sync/UFO Memory
participant GPU as GPU HW
App->>KM: Submit task A (refs UFO_X native)
KM->>FW: CCB: TA/3D + native fence(target)
FW->>GPU: Dispatch TA for Task A
GPU-->>FW: Complete -> FW writes Native UPDATE to UFO_X <-- (native fence complete)
Note over FW,UFO: Native fence written by FW (trusted)
App->>KM: Submit task B (depends on foreign UFO_Y)
KM->>FW: CCB: Wait FENCE(UFO_Y) then do 3D
FW->>UFO: Read UFO_Y (expect external update)
App->>UFO: (external producer) write update to UFO_Y
UFO-->>FW: Update read back
alt Update valid
FW->>FW: Continue execution (foreign satisfied)
else Invalid (format/value mismatch)
FW->>FW: Mark `<Invalid UFO update>` -> FWCtx waits `Waiting FENCE (foreign)`
FW-->>KM: stalls, SyncCP remains InUse
end
Note over KM,FW: Update Fence = the pattern where FW writes update for others to wait on (FW acts as producer)
