【HexVIO】DSP卸载双目惯性VIO：Hexagon向量化前端与单帧融合调度深度解析

摘要

移动端双目惯性 VIO（Visual-Inertial Odometry）长期受限于 CPU 功耗与续航：持续运行视觉前端会让设备在几小时内耗尽电池。HexVIO 把基于 Basalt 的双目 VIO 前端（图像金字塔、FAST-9 角点检测、逆向组合 KLT 跟踪）整体卸载到 Qualcomm Hexagon V73 DSP 上，后端非线性优化仍留在 CPU。其核心创新是把原本 6 次独立的 FastRPC 调用融合成每帧 1 次，配合 HVX 1024 位向量化与 VTCM 片上缓存，在 Galaxy S23（Snapdragon 8 Gen2）上实现 67% 功耗下降、86% 吞吐提升，0.83W 功耗下可用 15Wh 电池连续运行约 18 小时。

论文：HexVIO: Towards All-Day Stereo-Inertial Tracking Through Commodity DSPs

一、问题背景

VIO 是 AR/VR 眼镜、移动机器人等电池供电设备实现 6DoF 定位的核心模块，但传统 CPU 实现的前端（图像金字塔、特征检测、特征跟踪）是功耗大户。现有工作主要有两条路：

算法层减负：降低金字塔层数、减少特征点数、稀疏化跟踪------精度与功耗直接对立，天花板明显。
异构硬件加速：把前端卸载到 GPU 或专用 NPU------但 GPU 在移动 SoC 上功耗仍偏高，而大多数 NPU 面向卷积/矩阵运算设计，VIO 前端里 FAST-9、KLT 这类不规则、小尺寸、分支密集的计算并不天然适配。

HexVIO 选择了一条此前被低估的路径：手机 SoC 里普遍存在、但主要用于音频/传感器处理的 Hexagon DSP。它提供 1024 位 SIMD 向量单元（HVX）与片上高速缓存（VTCM），功耗远低于 GPU，但要把 VIO 前端的不规则计算模式映射上去，需要逐算法重新设计向量化策略，并解决 CPU↔DSP 频繁跨核调用（FastRPC）本身的开销问题------调用开销如果不解决，省下的计算时间会被通信开销吃掉。这正是本文要解决的核心问题。

二、核心方法

2.1 整体框架

HexVIO 的系统划分遵循一个原则：前端（感知）搬到 DSP，后端（估计）留在 CPU。前端包含图像金字塔构建、双目 FAST-9 角点检测、时域与双目方向的逆向组合 KLT 跟踪；后端的 IMU 预积分与滑窗非线性优化仍在 CPU 执行，因为这部分计算是稠密矩阵运算且对精度敏感，DSP 的向量化收益有限。
#mermaid-svg-X0S3rHfziAoOFBmP{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-X0S3rHfziAoOFBmP .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-X0S3rHfziAoOFBmP .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-X0S3rHfziAoOFBmP .error-icon{fill:#552222;}#mermaid-svg-X0S3rHfziAoOFBmP .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-X0S3rHfziAoOFBmP .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-X0S3rHfziAoOFBmP .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-X0S3rHfziAoOFBmP .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-X0S3rHfziAoOFBmP .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-X0S3rHfziAoOFBmP .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-X0S3rHfziAoOFBmP .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-X0S3rHfziAoOFBmP .marker{fill:#333333;stroke:#333333;}#mermaid-svg-X0S3rHfziAoOFBmP .marker.cross{stroke:#333333;}#mermaid-svg-X0S3rHfziAoOFBmP svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-X0S3rHfziAoOFBmP p{margin:0;}#mermaid-svg-X0S3rHfziAoOFBmP .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-X0S3rHfziAoOFBmP .cluster-label text{fill:#333;}#mermaid-svg-X0S3rHfziAoOFBmP .cluster-label span{color:#333;}#mermaid-svg-X0S3rHfziAoOFBmP .cluster-label span p{background-color:transparent;}#mermaid-svg-X0S3rHfziAoOFBmP .label text,#mermaid-svg-X0S3rHfziAoOFBmP span{fill:#333;color:#333;}#mermaid-svg-X0S3rHfziAoOFBmP .node rect,#mermaid-svg-X0S3rHfziAoOFBmP .node circle,#mermaid-svg-X0S3rHfziAoOFBmP .node ellipse,#mermaid-svg-X0S3rHfziAoOFBmP .node polygon,#mermaid-svg-X0S3rHfziAoOFBmP .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-X0S3rHfziAoOFBmP .rough-node .label text,#mermaid-svg-X0S3rHfziAoOFBmP .node .label text,#mermaid-svg-X0S3rHfziAoOFBmP .image-shape .label,#mermaid-svg-X0S3rHfziAoOFBmP .icon-shape .label{text-anchor:middle;}#mermaid-svg-X0S3rHfziAoOFBmP .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-X0S3rHfziAoOFBmP .rough-node .label,#mermaid-svg-X0S3rHfziAoOFBmP .node .label,#mermaid-svg-X0S3rHfziAoOFBmP .image-shape .label,#mermaid-svg-X0S3rHfziAoOFBmP .icon-shape .label{text-align:center;}#mermaid-svg-X0S3rHfziAoOFBmP .node.clickable{cursor:pointer;}#mermaid-svg-X0S3rHfziAoOFBmP .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-X0S3rHfziAoOFBmP .arrowheadPath{fill:#333333;}#mermaid-svg-X0S3rHfziAoOFBmP .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-X0S3rHfziAoOFBmP .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-X0S3rHfziAoOFBmP .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-X0S3rHfziAoOFBmP .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-X0S3rHfziAoOFBmP .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-X0S3rHfziAoOFBmP .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-X0S3rHfziAoOFBmP .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-X0S3rHfziAoOFBmP .cluster text{fill:#333;}#mermaid-svg-X0S3rHfziAoOFBmP .cluster span{color:#333;}#mermaid-svg-X0S3rHfziAoOFBmP div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-X0S3rHfziAoOFBmP .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-X0S3rHfziAoOFBmP rect.text{fill:none;stroke-width:0;}#mermaid-svg-X0S3rHfziAoOFBmP .icon-shape,#mermaid-svg-X0S3rHfziAoOFBmP .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-X0S3rHfziAoOFBmP .icon-shape p,#mermaid-svg-X0S3rHfziAoOFBmP .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-X0S3rHfziAoOFBmP .icon-shape .label rect,#mermaid-svg-X0S3rHfziAoOFBmP .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-X0S3rHfziAoOFBmP .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-X0S3rHfziAoOFBmP .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-X0S3rHfziAoOFBmP :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} DMA 双目图像
特征轨迹/新角点
观测
位姿/深度估计
相机驱动/回放
Hexagon cDSP 融合前端
CPU 前端调度
CPU 后端估计器

IMU预积分+滑窗优化

图1：系统整体架构图------CPU 侧保留相机驱动、前端调度与后端估计器；DSP 侧把金字塔构建、双目 FAST-9 检测、双目 KLT 跟踪 5 个子阶段全部打包进一次 FastRPC 调用完成，中间结果驻留 VTCM 8MB 片上缓存（4 个槛位：当前/上一帧 × 左/右图），避免反复经过 DDR。重点看：虚线是 CPU/DSP 的物理边界，融合调用框内的箭头表示 5 个子阶段在同一次 RPC 内顺序执行而非 6 次往返。来源：重绘自论文 Fig. 2 / Fig. 4，合并了硬件内存层级与系统分区两张图的信息。

这里的关键工程决策是"单帧一次调用"：如果金字塔、左图检测、右图检测、时域跟踪、双目跟踪、以及调度本身各发一次 FastRPC，每次调用的固定开销（约 0.25ms，turbo 频点下）会叠加 6 倍；融合成 1 次调用后，这部分开销只发生一次，详见第四节的实测数据。

2.2 关键模块一：图像金字塔与 FAST-9 检测

金字塔构建使用 4 级二项模糊（binomial blur）逐级下采样：

I l + 1 ( x , y ) = ∑ i = − 2 2 ∑ j = − 2 2 w i w j I l ( 2 x + i , 2 y + j ) I_{l+1}(x, y) = \sum_{i=-2}^{2}\sum_{j=-2}^{2} w_i w_j \, I_l(2x+i, 2y+j) Il+1(x,y)=i=−2∑2j=−2∑2wiwjIl(2x+i,2y+j)

其中 w w w 为二项近似高斯核权重， I l I_l Il 为第 l l l 层金字塔图像。向量化策略为像素并行：HVX 的 1024 位寄存器可容纳 64 个 16 位像素，每个 SIMD lane 独立处理一个像素的模糊结果，邻接像素在内存中连续排布，恰好匹配一次向量加载。

FAST-9 角点检测基于环形邻域的位掩码测试：对每个候选像素周围的 16 邻域像素，分别与中心像素比较得到"显著更亮"掩码 m k + m^+_k mk+ 与"显著更暗"掩码 m k − m^-_k mk−，若存在 9 个连续置位则判定为角点：

corner ( x , y ) = ∃ k : ⋀ i = 0 8 m ( k + i ) m o d 16 + ( x , y ) ∨ ⋀ i = 0 8 m ( k + i ) m o d 16 − ( x , y ) \text{corner}(x,y) = \exists\, k : \bigwedge_{i=0}^{8} m^{+}{(k+i)\bmod 16}(x,y) \;\lor\; \bigwedge{i=0}^{8} m^{-}_{(k+i)\bmod 16}(x,y) corner(x,y)=∃k:i=0⋀8m(k+i)mod16+(x,y)∨i=0⋀8m(k+i)mod16−(x,y)

同样走像素并行路线：8 位工作图下，每个向量块可并行测试 128 个候选像素。右图检测还做了一个工程优化------跳过已经从左图跟踪投影过来的区域，减少冗余检测。

2.3 关键模块二：逆向组合 KLT 跟踪

跟踪阶段采用逆向组合（inverse-compositional）KLT，残差定义在参考帧坐标系下，避免每次迭代都重新计算雅可比：

E ( Δ p ) = ∑ x ∈ R $I ( W ( x ; p \circ Δ p ) ) - T ( x )$ 2 E(\Delta\mathbf{p}) = \sum_{\mathbf{x}\in R} \left $I\\big(W(\\mathbf{x}; \\mathbf{p}\\circ\\Delta\\mathbf{p})\\big) - T(\\mathbf{x}) \\right$ ^2 E(Δp)=x∈R∑ $I(W(x;p\circΔp))-T(x)$ 2

Δ p = H − 1 ∑ x ∈ R ∇ T ( x ) ∂ W ∂ p ∣ p = 0 ⋅ $T ( x ) - I ( W ( x ; p ) )$ \Delta\mathbf{p} = \mathbf{H}^{-1} \sum_{\mathbf{x}\in R} \nabla T(\mathbf{x})\, \frac{\partial W}{\partial \mathbf{p}}\Big|_{\mathbf{p}=0} \cdot \left $T(\\mathbf{x}) - I(W(\\mathbf{x};\\mathbf{p}))\\right$ Δp=H−1x∈R∑∇T(x)∂p∂W p=0⋅ $T(x)-I(W(x;p))$

其中 R R R 为参考模板窗口， T T T 为参考图像块， W W W 为仿射变形函数， H \mathbf{H} H 为 Hessian 矩阵，通过 LDL ⊤ ^\top ⊤ 分解求逆。这一步的向量化策略与前两个模块不同，改为特征并行：一个 SIMD lane 对应一个特征点，32 个特征组成一批并行处理；对于已经跟踪失败、不需要继续迭代的特征，用 lane predication（谓词屏蔽）剔除而非分支跳转，保证 32 路求逆不因个别特征提前退出而分叉。

图2：核心算法流程图------三个阶段分别标注对应公式与向量化策略（①②为像素并行，③为特征并行），下半部分整合了 CPU/DSP 耗时对比与融合调用的收益数字。重点看：右下角"融合节省"的两个数字（2.3ms / 0.7ms）对应两种不同的 QoS 调度策略，差异原因在第三节说明。来源：重绘自论文正文公式、Fig. 3（向量化策略示意）、Fig. 5（分阶段耗时）、Fig. 6（融合调度收益），原图信息分散在三处，此图合并呈现。

三、工程实现

HexVIO 的硬件基础是 Hexagon V73 DSP，内部包含标量核心、HVX 向量单元（1024 位 SIMD）、HMX 矩阵单元，以及 VTCM 这块 8MB 的片上高速缓存------它是唯一能被 gather 指令直接寻址的内存层级，HexVIO 用它常驻 4 个金字塔槛位（当前帧/上一帧 × 左图/右图），避免每次访问都要穿透到 DDR。

图3：Hexagon V73 硬件层级原图。重点看 VTCM 相对 L2/DDR 的位置------它是向量化收益的关键，决定了金字塔数据能否常驻片上。来源：HexVIO 论文 Fig. 2。

值得注意的是，论文明确说明 HMX 矩阵单元没有被使用：原文给出的理由是"per-feature matrices too small to benefit from HMX"------KLT 跟踪里每个特征对应的 Hessian 矩阵规模太小（典型 2×2 到 6×6），矩阵单元的吞吐优势发挥不出来，反而是把计算映射到 HVX 向量 lane 上做特征并行更划算。这是一个容易被忽略但很重要的工程判断：不是所有能用上的硬件单元都该用。

图4：两种向量化策略对比原图------金字塔/检测阶段是像素并行（一个 lane 一个像素），跟踪阶段是特征并行（一个 lane 一个特征）。重点看两种策略下 lane 与数据的映射关系差异。来源：HexVIO 论文 Fig. 3。

图5：系统分区原图，与图1的自绘架构图对应。重点看融合调用框内 5 个子阶段的顺序关系。来源：HexVIO 论文 Fig. 4。

调度策略上，FastRPC 支持两种 QoS 模式：**自适应（adaptive）**模式下 DSP 频点随负载动态调整，**轮询（polling）**模式下 DSP 保持常驻高频等待任务。论文实测融合调用相比拆分 6 次调用，在自适应 QoS 下每帧节省 2.3ms，轮询 QoS 下节省 0.7ms------轮询模式本身没有频点切换开销，所以融合带来的边际收益更小，但仍然显著,因为固定调用开销（约 0.25ms/次，6 次叠加）是两种模式下都存在的共同成本。论文原文对这一设计决策的总结是："Fusing the per-stage dispatches into a single call per frame is what makes the efficiency operating points practical: with one call per frame instead of one per stage, the frontend can keep the power-saving RPC policy and still meet the deadline."------也就是说，融合调用不只是省了几毫秒，更关键的是让"省电"和"不丢帧"这两个原本冲突的目标同时成立。

四、实验分析

实验基于 EuRoC、Monado SLAM Dataset、TUM-VI 三个公开数据集，外加作者在 XREAL Air 2 Ultra AR 眼镜上自采的数据，共 8 个评测序列：EV102、EMH03、TR2、TR6、MOO02、MOO08、XWALK、XBIKE。

图6：功耗-吞吐权衡曲线（左）与轨迹误差对比（右）。重点看曲线整体左上偏移------同等吞吐下功耗更低，同等功耗下吞吐更高，这是硬件卸载类工作最核心的证据图。来源：HexVIO 论文 Fig. 1（左/右）。

核心数字：相比 CPU 基线，HexVIO 实现 67% 功耗降低、86% 吞吐提升 ，在 Galaxy S23（Snapdragon 8 Gen2）上以 0.83W 功耗维持 30fps，按 15Wh 典型手机电池容量估算可连续运行约 18 小时。前端总耗时从 CPU 的 6.6ms 降到 DSP 的 2.0ms，提速约 70%。

图7：8 个评测序列的场景样图，覆盖室内走廊、楼梯、骑行等多种运动模式。来源：HexVIO 论文 Fig. 1（下）。

图8：前端各子阶段（金字塔/跟踪/检测/匹配/RPC overhead）耗时分解。重点看 RPC overhead 这一项在拆分调用场景下占比明显更高。来源：HexVIO 论文 Fig. 5。

图9：融合调用 vs 拆分 6 次调用，在自适应/轮询两种 QoS 策略下的耗时柱状对比，对应第三节的 2.3ms/0.7ms 数字。来源：HexVIO 论文 Fig. 6。

可靠性方面，论文在全部 8 个序列上统计了**丢帧/错过处理截止时间（missed deadline）**次数：CPU 基线累计错过 342 次，DSP 自适应调度（DSPB）累计错过 21 次，DSP 轮询调度（DSPL）仅错过 1 次------这说明卸载到 DSP 不仅省电，实时性也明显更稳。论文额外做了一组 40 分钟的长时运行测试（序列 MOO12）：

图10：40 分钟长跑功耗/时钟/温度/延迟四联图。重点看温度曲线------DSP 配置全程稳定在 34-35°C，CPU 基线则持续攀升到 42°C，说明 DSP 方案在散热与降频风险上也更友好。来源：HexVIO 论文 Fig. 7。

在这次长跑测试中，DSP 配置的 SoC 温度全程稳定在 34-35°C，而 CPU 基线升到 42°C；延迟方面 DSP 配置的迟帧率 ≤0.05%，CPU 基线为 0.25%。温度曲线的稳定性意味着 DSP 方案不容易触发手机的降频保护，长时间运行的性能衰减风险更小------这对 AR 眼镜这类需要长期佩戴运行的设备尤其重要。

小结

HexVIO 的核心贡献不是"把 VIO 前端搬到 DSP"这个想法本身（硬件卸载早有先例），而是两个具体的工程判断：一是针对金字塔/检测/跟踪三类不同计算模式分别设计像素并行与特征并行两套向量化方案，而不是用一套策略硬套所有阶段；二是把 6 次 FastRPC 调用融合成 1 次，这个看似简单的改动实际上解决了"省电策略"与"实时性保证"互相矛盾的根本问题------没有融合调用，省电的自适应 QoS 策略会因为调用开销叠加而无法满足帧率要求。

局限性也很明确：论文目前的评测基于录制数据回放，并未在真实摄像头直连 DSP 场景下验证端到端延迟，原因是直接从 DSP 读取 L2 相机数据流需要厂商签名的底层驱动代码，不是简单的软件改动，依赖 OEM 级别的集成；后端的非线性优化仍留在 CPU，论文把它列为下一步的优化目标；作者也提到 Hexagon DSP 在 Qualcomm RB5 机器人套件、XR2/AR1 头显芯片、Snapdragon Ride 车规平台上均有部署，HexVIO 这套前端卸载思路具备跨产品线复用的潜力。个人判断：这篇工作的真正价值在于提供了一个"异构卸载不只是算力搬运，调用模式本身也是性能瓶颈"的具体反例------很多团队在做类似移植时只关注计算侧的向量化，容易忽略跨核调用频次带来的隐性开销，这一点值得其他做端侧硬件加速的团队参考。目前没有公开代码仓库，论文页脚注明源码将在后续发布。