基于ARM Compute Library，ORB特征检测与描述能否移植至ARM Mali GPU？

没错，确实有不少开发者成功把ORB的特征检测与描述模块移植到ARM Mali GPU上，而且大多是基于ARM Compute Library来做硬件加速的——毕竟你提到的这个库本身就提供了大量成熟的GPU加速原语，刚好能用来搭建ORB的整个流程。

下面整理几个关键信息点，帮你理清思路：

• ARM Compute Library没有原生ORB，但有足够的"积木"
  这个库本身确实没直接封装ORB的完整实现，但它包含了ORB核心步骤需要的所有底层加速组件：比如GPU版的高斯金字塔生成、FAST角点检测、像素级运算、阈值处理这些。你完全可以把这些组件像搭积木一样组合起来，拼成完整的ORB pipeline。

• 已有的移植思路和实操细节
  很多嵌入式视觉开发者的做法是基于Compute Library的OpenCL后端（Mali GPU用的就是OpenCL）来重构ORB：

  1. 图像金字塔：直接用库中的GaussianPyramid模块在GPU上生成，这一步比CPU快不少；
  2. 特征点检测：用库自带的FastCorners（支持GPU加速）替代ORB原生的FAST检测，再加上尺度不变性的筛选逻辑；
  3. 描述符计算：ORB的二进制描述符本质是灰度值比较，这部分可以用Compute Library的像素级乘法、阈值操作来模拟，或者直接写轻量的自定义OpenCL内核，利用GPU的并行性批量计算描述符。

• 性能提升的实际表现
  从一些开发者分享的测试结果来看，在Mali-G77这类中高端GPU上，GPU加速的ORB比优化过的NEON CPU版本能快2-4倍，尤其是处理1080P以上的高分辨率图像时，GPU的并行优势会更突出，完全能进一步提升实时性能。

• 需要避开的几个坑

  • 内存拷贝开销：CPU和GPU之间的数据传输很容易成为瓶颈，尽量用Compute Library的Tensor或Image类来管理显存，减少不必要的内存拷贝；
  • 内核适配：如果要写自定义OpenCL内核，得适配Mali GPU的架构（比如SIMD宽度、缓存策略），不然可能加速效果打折扣；
  • 精度对齐：要确保GPU版本的特征点和描述符和CPU版本结果一致，避免因为并行计算顺序或浮点精度问题导致匹配出错。

内容的提问来源于stack exchange，提问作者homeStayProg