看過來，RK3576開發板NPU方案你用對了嗎？
加入技術交流群
圖 米爾基于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 平臺。
評論