看过来，RK3576开发板NPU方案你用对了吗？
编者按：本文基于米尔MYD-LR3576开发板，详细记录了如何利用500万像素USB摄像头实现640×640分辨率的YOLO5s目标检测，并将结果实时输出至1080P屏幕的全流程。通过系统级的软硬件协同优化，最终将端到端延迟控制在40ms以内，实现了20FPS的稳定实时检测性能。文章重点剖析了摄像头特性分析、显示通路选择、RGA硬件加速、RKNN NPU集成等关键技术环节，为嵌入式AI视觉系统的开发与调优提供了一套完整的思路与实践方案。
图 米尔基于RK3576核心板开发板
一、 系统架构与性能目标
1.1 硬件平台
● 主控芯片：Rockchip RK3576（四核A72+四核A53，6TOPS NPU，RGA,GPU,VPU）
● 摄像头：500万像素USB摄像头（支持MJPEG/YUYV格式）
● 显示器：4K HDMI显示屏（通过Weston桌面环境显示）
● 开发板：米尔MYD-LR3576
1.2 软件平台
使用米尔官方 V2.0.0 SDK 提供的 buildroot 镜像，内核版本为 6.1.118。
系统信息如下：
root@myd-lr3576-buildroot:/# uname -a
Linux myd-lr3576-buildroot 6.1.118 #1 SMP Fri Sep 26 02:34:15 UTC 2025 aarch64 GNU/Linux
1.3 性能目标
● 实时性：完成从摄像头采集 → NPU推理 → 屏幕显示的完整流程，耗时不超过摄像头一帧的时间。
● 输入/输出：尽可能提高摄像头采集帧率，并在显示端支持更高的输出分辨率。
● 功能：实现 YOLO5s 目标检测，并在视频画面中实时绘制检测框。
二、数据处理流程与优化实践
摄像头数据需要经历哪些过程才能到显示端输出，参考下图
2.1 CPU处理方案及其瓶颈
如果把摄像头数据直接显示到屏幕上，先了解清楚它们输入输出关系。
摄像头输出可以用v4l2-ctl -D -d /dev/videoxx --list-formats-ext
Display输出可用用cat /sys/kernel/debug/dri/0/state查看
根据实时性来说，需要选择最高fps分辨率对应输出，这里选择640x480 20fps，那么它需要把YUYV格式替换成RGBA8888才能显示。
显示大小不超过屏幕最大分辨率3840x2160即可。
CPU处理是如下过程
若要将摄像头采集的 YUYV 格式数据直接显示到屏幕，需先转换为 RGBA8888 格式。在 CPU 上进行格式转换与缩放的性能如下（输入为 640×480 YUYV）：
目标分辨率 | YUV转换耗时 | 缩放耗时 | 总耗时 | 理论FPS |
1920×1080 | 8ms | 25ms | 33ms | ~30 |
2560×1440 | 8ms | 46ms | 54ms | ~18 |
3840×2160 | 8ms | 103ms | 111ms | ~9 |
可见，CPU 在处理 1080P 分辨率时已接近能力上限，更高分辨率则无法满足实时性要求。
2.2 引入RGA进行硬件加速
RGA作为RK3576 2D处理芯片模块，它的作用是对图片做旋转，缩放，旋转，镜像以及格式转换。
根据手册信息，它能处理数据的性能是 物理地址 > dma > 虚拟地址。那么用RGA来替换CPU的格式转换和缩放。
RGA是一次进行转换和缩放，下面是对比CPU运算的对比图
使用 RGA 替代 CPU 进行格式转换与缩放后，性能对比如下：
目标分辨率 | CPU方案总耗时 | RGA [virtual addr] | RGA [dma] |
1920×1080 | 33ms | 7ms | 2ms |
2560×1440 | 54ms | 10ms | 3ms |
3840×2160 | 111ms | 20ms | 7ms |
RGA的引入带来了数量级的性能提升，尤其是DMA模式，大幅降低了处理延迟。
2.3 GPU直接显示方案
调试阶段常使用 OpenCV 的 imshow 显示图像，但其依赖 CPU 参与，无法满足实时性要求。系统实际采用 DRM 显示框架与 Weston 桌面环境，因此我们选用 Wayland-client 方案进行直接显示，实现 GPU 直显。
不同输入模式下的显示耗时对比：
输入分辨率 | Virtual addr显示耗时 | DMA显示耗时 |
1920×1080 | 3ms | 0 ms |
2560×1440 | 5~9ms | 0 ms |
3840×2160 | 13~16ms | 0 ms |
2.4 NPU推理流程与耗时分析
通用模型，通过rknn-toolkit2转换成rknn后就可以通过RKNN API来调用和推导。
这里我们直接采用同事提供的rknn模型，yolov5s-640-640.rknn和coco_80_labels_list.txt，以及一些调用参考代码。
它的输入必须是640x640RGB格式
rknn推理虚拟地址关键步骤如下
步骤 | API调用 | 关键操作 | 注意事项 |
初始化 | rknn_init | 初始化NPU | |
初始化 | rknn_set_core_mask | 设置绑定NPU core0还是core1，还是自动 | 推荐自动 |
初始化 | rknn_query | 查询输入和输出个数 | |
准备 | rknn_inputs_set | 设置输入数据 | 数据格式必须匹配 |
推理 | rknn_run | 执行NPU推理 | 耗时主要瓶颈 |
获取 | rknn_outputs_get | 获取推理结果 | 可选want_float |
释放 | rknn_outputs_release | 释放输出资源 | 必须调用，防泄露 |
实际测试后rknn_run 这个阶段大概耗时 26~31ms之间
rknn_outputs_get 获取数据后即可进行内部处理，检测出目标，坐标，信心指数，根据实际需求绘制在屏幕上，这一步可以多进程异步处理，不算在串行时间内，笔者测试大概会多花8ms左右。
因此 总计一下摄像头实时采集NPU推理到显示整个过程耗时情况
数据类型 | 输出分辨率 | T1 | T2 | T3 | T4 | 总时间 | 理论FPS |
虚拟地址 | 1920x1080 | 0 | 26~31 | 7 | 3 | 36~41 | ~30 |
2160x1440 | 10 | 5~9 | 41~50 | 25 | |||
3840x2160 | 20 | 13~16 | 59~67 | 19 | |||
Dma | 1920x1080 | 27~40 | 2 | 0 | 29~42 | ~34 | |
2160x1440 | 3 | 0 | 30~43 | ~30 | |||
3840x2160 | 7 | 0 | 34~47 | ~31 |
结论：NPU 推理阶段（T2）仍是系统的主要耗时环节。但通过 DMA + RGA + 直接显示 的优化组合，系统整体延迟大幅降低，且在高分辨率输出下仍能保持稳定的帧率。
2.5 多摄像头系统资源占用分析
● 虚拟内存方案
1个摄像头
4个摄像头
● Dma方案
1路摄像头输出
2路摄像头输入
三、总结
在嵌入式 AI 视觉系统中，NPU 的算力是决定性能上限的关键因素。然而，要达到这一上限，必须构建高效的数据流水线。本文实践表明，通过 RGA 硬件加速、DMA 零拷贝数据传输以及 GPU 直接显示 的协同优化，能够彻底释放 RK3576 平台的异构计算潜力，将端到端延迟控制在数十毫秒内，实现高清、实时的目标检测应用。这一优化思路同样适用于其他具备类似硬件加速单元的嵌入式 AI 平台。
加入微信
获取电子行业最新资讯
搜索微信公众号：EEPW
或用微信扫描左侧二维码