3、Pipeline调度框架：高通平台（CamX/CHI）架构、MTK平台（ISP 3.0/4.0）架构、华为平台（XDFusion）架构对比
做手机影像系统这么多年，我接触过不少平台。高通、MTK、华为这三家，Pipeline调度思路完全不同。说白了，它们都在解决同一个问题：怎么让多颗摄像头、多种算法、多个处理单元高效协同。但各自的解法，嗯，差别还挺大。
今天我就把这三家的架构掰开揉碎了讲。你想想看，理解了它们的差异，以后做平台适配或者性能调优，心里就有底了。
3.1 高通平台：CamX + CHI 架构
高通的方案，我接触得最早。从 Snapdragon 845 开始，高通就把老旧的 mm-camera 架构换成了 CamX（Camera eXtension）。配合 CHI（Camera Hardware Interface），这套架构的核心思路是「模块化」和「可配置化」。
我个人习惯把 CamX 架构分成三层：
- UPL（Usecase Pipeline Layer）：最上层，负责定义拍照、录像、HDR 等业务场景。每个 Usecase 对应一条逻辑 Pipeline。
- CSL（Camera Service Layer）：中间层，负责 Pipeline 的调度、Session 管理、Buffer 流转。这是调度核心。
- CHI（Camera Hardware Interface）：最底层，直接跟硬件打交道。ISP、传感器、EIS 模块都在这一层。
关键点：高通用 XML 描述文件来定义 Pipeline 拓扑。你改 XML 就能调整算法节点顺序，不用改驱动代码。我在项目中遇到过，客户想加一个自定义的美颜节点，只需要在 XML 里插入一个 Node，再注册对应的算法库就行。这种灵活性，确实省事。
来看一个典型的 CamX Pipeline 调度流程：
// 伪代码：CamX Pipeline 创建与调度
CamX::CreatePipeline("preview_use_case");
CamX::AddNode("SensorNode", 0);
CamX::AddNode("IFENode", 1);
CamX::AddNode("IPENode", 2);
CamX::AddNode("DisplayNode", 3);
CamX::LinkNodes(0, 1); // Sensor -> IFE
CamX::LinkNodes(1, 2); // IFE -> IPE
CamX::LinkNodes(2, 3); // IPE -> Display
CamX::StartPipeline();
这里要注意，高通的调度是 事件驱动 的。每个 Node 完成处理后，会触发一个回调，通知下一个 Node 开始干活。这种机制的好处是延迟低，但坏处是——如果某个 Node 处理时间不稳定，整个 Pipeline 就会抖动。
避坑指南：我曾经在调试高通的 HDR 场景时，发现预览帧率突然掉到 15fps。查了半天，原来是 IFE Node 在处理多帧合成时，Buffer 分配策略没配好，导致 Pipeline 阻塞。后来我把 Buffer 池从 4 个增加到 6 个，问题就解决了。所以，高通平台调优，Buffer 数量是个关键参数。
3.2 MTK 平台：ISP 3.0 / 4.0 架构
MTK 的架构，跟高通思路不太一样。MTK 更强调 硬件流水线 和 固件调度。从 ISP 3.0 到 4.0，MTK 把越来越多的处理逻辑从 AP（应用处理器）搬到了 ISP 内部的硬件加速器上。
MTK 的 Pipeline 调度，核心是 P1/P2/P3 三级流水线：
- P1（Pre-ISP）：传感器数据接收、坏点校正、黑电平校正。纯硬件处理，延迟极低。
- P2（Main-ISP）：去马赛克、降噪、色彩校正、伽马校正。这部分有硬件加速，也支持部分软件算法。
- P3（Post-ISP）：人脸检测、场景识别、美颜、HDR 合成。这部分主要是软件算法，跑在 AP 的 DSP 或 GPU 上。
我刚开始接触 MTK 平台时，最不习惯的是它的 固件调度表。MTK 用一张静态的调度表来定义每一帧的处理流程。这张表在系统启动时就加载到 ISP 固件里，运行时基本不改。
| 阶段 | 处理模块 | 硬件/软件 | 典型延迟 |
|---|---|---|---|
| P1 | Sensor RAW 接收、BLC、DPC | 纯硬件 | < 0.5 ms |
| P2 | Demosaic、NR、CCM、Gamma | 硬件 + 微码 | 2-4 ms |
| P3 | FD、AWB、AE、美颜 | 软件（DSP/GPU） | 5-15 ms |
个人经验：MTK 平台调优，重点在 P2 和 P3 的负载均衡。如果 P3 的算法太重，会导致 Pipeline 整体延迟增加。我建议把一些计算量大的算法（比如多帧降噪）放到 P2 的硬件加速器上做，别全堆在 P3。MTK ISP 4.0 开始支持硬件多帧融合，这个特性一定要用起来。
MTK 的调度还有一个特点：它支持 多路并行 Pipeline。比如同时跑预览和录像，MTK 会创建两条独立的 Pipeline，共享 P1 阶段的 RAW 数据，但 P2 和 P3 各自独立。这种设计，说白了就是「一次采集，多次处理」。
3.3 华为平台：XDFusion 架构
华为的 XDFusion，是我见过最「激进」的架构。它把 ISP、NPU、DSP、GPU 全部融合到一个统一的调度框架里。你想想看，这相当于把整个影像处理系统当成一个超级计算机来调度。
XDFusion 的核心思想是 异构计算 + 动态编排。它不再像高通和 MTK 那样有固定的硬件流水线，而是把每个处理单元抽象成一个「算子」，然后根据当前场景动态组合这些算子。
举个例子，在夜景模式下，XDFusion 会这样调度：
- ISP 硬件：采集多帧 RAW 数据，做初步降噪。
- NPU：运行深度学习模型，做语义分割和场景识别。
- DSP：做多帧对齐和融合。
- GPU：做最终的色调映射和色彩增强。
这些算子不是固定的。如果场景简单，XDFusion 会跳过 NPU 和 GPU，只用 ISP 和 DSP 处理。这种动态编排的好处是——能效比极高。我在华为的实验室看过数据，同样的夜景拍照，XDFusion 的功耗比传统架构低了 30% 以上。
关键差异：XDFusion 的调度是 数据流驱动 的。每个算子处理完数据后，会把结果写到共享内存池，然后通知下一个算子来取。这种机制跟高通的回调驱动有点像，但 XDFusion 的调度粒度更细——它可以在算子级别做动态负载均衡。
不过，XDFusion 也有缺点。它的调度框架太复杂，调试起来非常困难。我曾经帮一个合作伙伴调试华为平台的录像卡顿问题，发现是 NPU 算子和 ISP 算子之间的 Buffer 同步没做好，导致 Pipeline 出现了微秒级的等待。这种问题，在传统架构上基本不会出现。
3.4 三家架构对比总结
好了，三家都讲完了。我画了一张对比图，帮你直观理解它们的差异：
最后说一句，没有完美的架构。高通的 XML 配置虽然灵活，但 XML 解析本身也有性能开销。MTK 的固件调度表虽然稳定，但改起来麻烦。华为的 XDFusion 虽然能效高，但调试工具链还不够成熟。你选平台的时候，得看自己的团队擅长什么。