RK3588实战：用RGA硬件加速图像预处理，告别CPU瓶颈

先聊个现象。最近在RK3588上跑视觉项目，最直观的感受是：这块芯片的NPU算力确实猛，6 TOPS摆在那，跑YOLOv8的s版本可以很轻松，但真到了做产品落地，很多人会发现瓶颈根本不在NPU，而在图像预处理那一大段。

摄像头出来的数据是NV12、BGR、MJPEG各种格式，进推理框架之前要先缩放、再转RGB、有时候还要旋转裁剪。这一套组合拳如果全扔给CPU硬扛，1080P的一帧处理下来十几毫秒就没了，哪怕NPU推理只要5毫秒，整个流水线还是被预处理卡死。后来我把预处理切到RGA硬件加速库上，同样是1080P转640x640，处理时间直接压到1毫秒上下，CPU占用率从百分之六七十掉到个位数。这篇就是把我在RK3588上折腾RGA的完整记录整理出来，接口怎么调、内存怎么对齐、哪些格式组合会踩坑，都一并说清楚，给同样在搞RK3588视觉方案的朋友做个参考。

1. RGA到底是什么：为什么视觉项目离不开它

1.1 RK3588的硬件加速矩阵里，RGA扮演什么角色

RK3588是一颗典型的"全家桶"SoC，4颗A76大核加4颗A55小核，NPU算力6 TOPS，GPU是Mali-G610，VPU支持8K编解码。很多人只盯着NPU看，却忽略了芯片上还有一票专用硬件单元，其中RGA就是一个存在感不高但极其重要的角色。

RGA全称Raster Graphic Acceleration，直译是光栅图形加速，本质是一个2D图像硬件加速引擎。它不负责渲染3D场景，也不负责神经网络推理，它干的事情非常专一：图像缩放、格式转换、旋转、镜像、裁剪、颜色空间转换、alpha混合。这些操作在视觉流水线里出现的频率极高，而且计算模式高度固定，非常适合用专用硬件流水线去跑。

打个比方，CPU就像一个多才多艺的师傅，什么活都能揽，但每单活都要重新沟通、重新准备工具；RGA则是一条专线传送带，只处理图像搬运和变形这几种固定操作，你把图放到入口，参数设好，它轰轰隆隆几毫秒就把活干完了。在RK3588的架构里，NPU负责推理算力，GPU负责复杂渲染，VPU负责编解码，RGA负责的是图像数据在各个环节之间的"精加工"和"转车"。视觉流水线里的预处理环节，刚好就落在RGA头上。

我在实际项目里体会到，RK3588这颗芯片的每一块硬件单元都对应一个典型的业务场景，如果你把图像预处理这种重复性极高的操作压在CPU上，A76大核再多也不够用，因为一帧图像转格式涉及几百万次像素访问，纯软件循环的效率远不如专用硬件。而RGA这种固定功能硬件，功耗低、时延小、不占CPU，对于高分辨率视频流的实时处理是刚需。

1.2 RGA能干的活比你想的多

RGA处理的基本元素是图像buffer，所有操作都可以归类为"从源buffer读数据，经过变换，写入目标buffer"。单次RGA操作可以同时组合缩放、格式转换、旋转、裁剪、镜像等多个属性，不需要拆成多次调用。这一点非常关键，意味着你可以把三步操作压成一次硬件调用。

具体能力可以列一下：

• 图像缩放：支持任意比例的放大缩小，输出宽高由目标矩形决定，比如4K缩到640x640，也可以只缩到640x480这种非等比尺寸。
• 格式转换：支持RGB/RGBA/BGR各通道顺序、YUV的各种采样格式（NV12、NV21、YUV420P、YUV422等）之间的互相转换，这是摄像头数据接入视觉模型最常用的功能。
• 旋转与镜像：支持90度、180度、270度旋转，以及水平、垂直镜像。
• 裁剪与ROI：可以从大图中抠出一块区域做后续处理，配合缩放可以实现"缩放裁剪"的效果。
• Alpha混合：支持两路图像叠加混合，常用于UI叠加和视频合成。

在我做USB摄像头转RTSP推流的项目里，RGA的作用非常典型。UVC摄像头输出的通常是YUYV或者MJPEG格式，要推RTSP流，一种做法是软解码成YUV再喂给编码器，另一种做法是先用RGA把YUV转成编码器最擅长的NV12格式，顺便把分辨率统一成720P或1080P，然后在编码器侧做硬编。这样整条链路都是硬件在跑，CPU占用几乎可以忽略。

1.3 RGA和CPU处理的实际差距

说个实测数据。在RK3588上，用CPU纯C代码把一张1920x1080的NV12图像转成RGB888，再缩放到640x640，普通优化大概需要15到20毫秒，哪怕上NEON指令集优化，也得8到10毫秒。同样的操作交给RGA，一次imresize调用同步完成，实测在1毫秒左右。

这个差距不是简单的"快了一点点"，而是量级的差别。假设你跑YOLOv8s，NPU推理一帧大约10毫秒出头，如果用CPU做预处理，整帧延迟直接变成30毫秒，帧率只能做到30FPS多一点；换RGA预处理，整帧延迟控制在15毫秒以内，跑到60FPS都没有压力。在视频实时分析这种场景里，这十几毫秒就是能不能用的分水岭。

2. 环境准备：把librga跑起来的前置工作

2.1 硬件运行环境怎么选

RGA是RK3588芯片内置的硬件模块，只要芯片是RK3588，不管跑什么系统，RGA都真实存在。但能不能用、好不好用，取决于软件包里有没有带RGA的用户态驱动库。

我试过三种环境：

• 官方SDK编译的Ubuntu系统：最省心，SDK已经把librga相关的头文件和动态库打进系统了，直接开发就行。
• Armbian系统：大部分基于RK3588的Armbian镜像也带了RGA驱动，但用户态librga不一定默认安装，需要自己装或者从源码编译。
• Android系统：Android上也有RGA的HAL封装，但应用层跨调用比较麻烦，通常是在C++层通过hardware module访问，做系统级优化时才会碰。

对于做视觉算法的朋友，首选是Ubuntu Server或带桌面的Ubuntu，原因很简单：生态成熟、gcc/cmake齐全、调试方便。RK3588的Ubuntu系统默认就映射了/dev/rga这个设备节点，这是RGA驱动的用户态入口。

先检查一下设备节点：

ls -l /dev/rga

如果能看到类似crw-rw---- 1 root video 10, 110的输出，说明RGA驱动已经就位。权限不够的话，把当前用户加到video组：

sudo usermod -aG video $USER

重新登录后就能直接访问了。

2.2 librga的获取与版本选择

用户态操作RGA的库叫librga，在RK3588上配套的是较新的版本，提供了一套IM2D（2D Image Manipulation）接口。这里有一个特别重要的点：librga的老接口和新接口差异非常大。

老版本使用rga_info_t结构体配合rk_rga_blit函数，暴露的细节多，门槛高，而且很多博客教程写的是这种老接口，直接抄过来在新SDK上很可能编译不过。新版本推荐IM2D接口，用rga_buffer_t描述buffer，用imresize、imconvert、imrotate这类语义化函数，代码简洁不少，对新手友好得多。

怎么获取librga？两种途径：

• SDK自带：在瑞芯微SDK的external/目录下一般有librga源码，编译整个SDK时会自动装到系统里。
• 从源码独立编译：可以从开源仓库拉取librga代码，编译安装到目标板。

编译librga的过程不复杂，建议在开发板上直接编，省得交叉编译的麻烦：

mkdir -p build cd build cmake .. make -j4 sudo make install

装完之后系统里会有/usr/include/rga目录，头文件包括rga.h、im2d.h等，动态库是librga.so。确认一下：

ls /usr/include/rga ls /usr/lib/librga.so*

如果你的系统版本比较老，可能会遇到找不到im2d.h的情况，那说明librga版本太旧，建议从源码升级新版。

2.3 写第一个程序时的编译配置

在CMakeLists.txt里，关键是找到头文件和库。

find_path(RGA_INCLUDE_DIR NAMES rga/im2d.h) find_library(RGA_LIBRARY NAMES rga) include_directories(${RGA_INCLUDE_DIR}) target_link_libraries(your_target ${RGA_LIBRARY})

RGA库本身依赖libdrm，链接的时候一般不需要手动加，因为librga会传递依赖，但如果你用到了drm相关的buffer管理函数，也需要单独找libdrm。

到这里环境就绪了，下面开始写代码。

3. 从调用接口开始：RGA编程模型

3.1 四个核心概念先理清楚

RGA编程模型不复杂，但要先理解四个概念。

第一个是源buffer和目标buffer。RGA操作基本都有输入和输出，输入描述的是"原图像长什么样"，输出描述的是"目标图像要长成什么样"，它们格式可以不同，尺寸可以不同。

第二个是关键属性width、height和stride。width/height好理解，stride是很多新手栽跟头的地方。stride指的是内存中一行像素实际占用的字节数或像素数，它不一定等于width。摄像头、GPU、显示控制器分配内存时通常会对行做对齐，比如一行1280像素的NV12，实际stride可能是1280、1284或1288，取决于对齐方式。如果直接按width处理，画面就会出现斜条纹或者颜色偏移。

第三个是format。RGA使用RK_FORMAT_XXX系列宏来表示格式，比如RK_FORMAT_RGB_888、RK_FORMAT_RGBA_8888、RK_FORMAT_YCrCb_420_SP（对应NV12）。格式定义在rga.h里，使用前务必搞清楚摄像头输出的到底是什么格式，搞错了RGA直接报错或者出花屏。

第四个是buffer的来源。RGA支持三种来源：虚拟地址、物理地址、dma_buf文件描述符。虚拟地址最简单，直接传指针；物理地址需要驱动层才能拿；dma_buf fd最安全，也是我在项目中推荐的方式，因为它能正确处理跨硬件访问时的cache同步问题。

3.2 用IM2D接口完成第一次缩放

用IM2D接口写一个缩放程序，代码核心只有几步。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include "im2d.h" #include "rga.h" int main() { int src_w = 1920, src_h = 1080; int dst_w = 640, dst_h = 640; void *src_ptr = NULL; void *dst_ptr = NULL; src_ptr = malloc(src_w * src_h * 3 / 2); dst_ptr = malloc(dst_w * dst_h * 3); if (!src_ptr || !dst_ptr) { printf("malloc failed\n"); return -1; } memset(src_ptr, 0, src_w * src_h * 3 / 2); memset(dst_ptr, 0, dst_w * dst_h * 3); rga_buffer_t src = wrapbuffer_virtualaddr(src_ptr, src_w, src_h, RK_FORMAT_YCrCb_420_SP); rga_buffer_t dst = wrapbuffer_virtualaddr(dst_ptr, dst_w, dst_h, RK_FORMAT_RGB_888); IM_STATUS ret = imresize(src, dst); if (ret != IM_STATUS_SUCCESS) { printf("imresize failed, status=%d\n", ret); return -1; } printf("RGA resize ok\n"); free(src_ptr); free(dst_ptr); return 0; }

这段代码做的事情是：读入一张1920x1080的NV12数据，在RGA硬件内部完成从NV12到RGB888的格式转换，同时把尺寸缩放到640x640，输出到dst_ptr指向的内存里。缩放和格式转换这两件事，RGA一次调用就完成了。

很多人会疑惑，直接用虚拟地址就行吗？对于带MMU的RGA版本来说是可以的，RK3588上的RGA通过内部MMU访问虚拟地址，映射和cache同步由驱动处理。不过对于性能要求比较高的场景，我更推荐使用dma_buf fd的方式，这个后面说。

3.3 输出路径上有哪些坑

wrapbuffer_virtualaddr这个系列函数还有一个带stride参数的版本，非常重要：

rga_buffer_t src = wrapbuffer_virtualaddr_t(src_ptr, src_w, src_h, src_wstride, src_hstride, RK_FORMAT_YCrCb_420_SP);

如果你的图像内存不是紧密排列的，比如从DMA buffer里映射来的帧，每行有额外的padding，就必须把wstride传进去。否则RGA按紧密排列去读，取出来的图像就是歪的。

还有一个坑，RGA的stride对齐要求在不同系统版本上不一样。有些版本要求16像素对齐，有些要求64字节对齐。最稳妥的做法是：不管内存怎么来的，都把你的wstride显式设置为对齐后的值。比如你实际width是1280，但镜头分配的内存stride是1280，就直接用1280，如果你的buffer每行实际占1296字节，就老老实实传1296。

format的坑也很常见。RK_FORMAT_YCrCb_420_SP对应的是NV12，RK_FORMAT_YCbCr_420_SP对应NV21，这俩容易搞混。NV12是YUV420半平面格式，UV分量排列是U在前V在后，NV21相反。摄像头驱动里最常输出NV12或者NV21，YOLOv8预处理阶段一般要转成RGB，我用NV12比较多，代码里也要保持一致。

4. 实战：YOLOv8部署里的预处理加速

4.1 一条完整的推理链路应该怎么设计

RK3588上部署YOLOv8，典型链路是这样的：摄像头采集视频帧，经过RGA做缩放、格式转换、必要的裁剪，得到模型输入尺寸的RGB数据，然后通过rknn_inputs_set喂给NPU，NPU推理完输出结果，最后后处理画出检测框。

这一步里，预处理放在哪里执行，直接决定了整条流水线的性能。

我最早偷懒用OpenCV的cvtColor和resize，一条1080P NV12转640x640 RGB的流程，在RK3588上CPU占用率飙到70%以上，帧率还不稳定。后来把预处理全部切到RGA，情况完全改观。

4.2 用RGA接管模型的输入预处理

假设摄像头输出NV12，1920x1080，模型输入是640x640 RGB，参考逻辑如下。

// nv12_ptr来自摄像头驱动/解码器 // model_input_ptr指向rknn_input的buffer，尺寸是640*640*3 rga_buffer_t src = wrapbuffer_virtualaddr(nv12_ptr, cam_w, cam_h, RK_FORMAT_YCrCb_420_SP); rga_buffer_t dst = wrapbuffer_virtualaddr(model_input_ptr, 640, 640, RK_FORMAT_RGB_888); if (imresize(src, dst) != IM_STATUS_SUCCESS) { LOGE("rga preprocess failed"); }

然后模型推理：

rknn_input input; memset(&input, 0, sizeof(rknn_input)); input.index = 0; input.type = RKNN_TENSOR_UINT8; input.size = 640 * 640 * 3; input.fmt = RKNN_TENSOR_NHWC; input.buf = model_input_ptr; input.pass_through = 0; rknn_inputs_set(ctx, 1, &input); rknn_run(ctx, nullptr);

注意，rknn_input.buf直接指向RGA的输出地址，中间没有用memcpy再拷一道，减少了内存拷贝的开销。如果你担心RGA写入和NPU读入之间会有cache一致性问题，在实际测试中，RGA和RKNN在RK3588的同一个统一内存架构里配合得不错，只要保证buf指针有效且等待RGA操作完成即可。

IM2D接口的imresize默认是同步等待完成的，也就是说调用返回时，目标buffer里的数据已经可用了，不需要额外做同步。这在大对数应用里很省心。

4.3 多路摄像头场景下的调度

如果项目是4路甚至8路摄像头同时做检测，每路的预处理都调RGA会怎么样？

RGA硬件只有一个处理单元，多个线程同时调用时，驱动会在内核层排队。实测下来，RGA排队处理4路1920x1080转640x640，整体预处理耗时还是有保障的，因为单帧RGA处理只需要1毫秒左右，4路的排队任务积累也不明显。

但要注意一个调度策略：不要为每路摄像头开一个线程去频繁调用RGA，这样线程切换和锁竞争反而增加开销。更好的做法是采集线程和推理线程分离，采集线程负责把帧送入队列，推理线程从队列取帧后统一走RGA预处理，再交给NPU。这样RGA的调用是串行且有序的，内核排队次数少，端到端的帧率更稳定。

4.4 带裁切的预处理：YOLOv8的letterbox

YOLOv8官方预处理通常做letterbox，把原始图像等比缩放到640x640内部，四周填充灰色。之前的做法是用OpenCV的resize加copyMakeBorder，这两个操作在CPU上都有不少耗时。

换成RGA后，可以分两步走：

第一步，用imresize把NV12缩放到一个等比尺寸，比如从1920x1080缩放到640x360。

第二步，构造一个640x640的目标buffer，用imfill填充灰色，再用RGA的imblend或者直接经RGA裁剪+混合把缩放后的图像放到目标区域。

严格来说，一次RGA操作做不了带填充的letterbox，因为letterbox包含两张图的操作。但在实际项目中，我发现很多时候不需要严格letterbox。如果你的模型训练时是按等比缩放+填充的方式，那可以把两步分开做，性能仍然比CPU方案快很多；如果模型可以接受直接拉伸缩放，那干脆一次imresize搞定，速度最快。

5. 性能调优与避坑指南

5.1 性能对照：RGA vs CPU

下面这组数据来自我在RK3588 Ubuntu系统上的实际测量，操作内容是1920x1080 NV12转640x640 RGB888，各跑100帧取平均。

差距非常悬殊。这也是为什么我反复强调，在RK3588上做视觉，RGA不是可选项，而是必选项。凡是涉及图像缩放、格式转换的操作，都应该优先考虑用RGA去扛。

5.2 常见问题排查速查表

实际使用RGA的过程中，几乎每个人都会碰到下面这几个问题。

5.3 独家避坑经验

第一个经验，尽量用dma_buf fd而不是裸虚拟地址。虽然IM2D接口用虚拟地址简单方便，但虚拟地址方式涉及RGA驱动的mmap和cache操作，在高分辨率、高频调用时偶尔会出现内存同步问题。用dma_buf fd可以确保RGA访问和CPU访问之间的一致性更可控。在实际项目中，如果你从摄像头驱动或者解码器拿到的本身就是dma_fd，就直接传给wrapbuffer_fd。

第二个经验，RGA的格式支持列表不要背文档，要实测。瑞芯微文档里会列一长串支持的格式和转换组合，但不同版本的RGA硬件和支持列表有微调。我在项目里就遇到过文档说支持RGBA转NV12，实际调用却失败的情况。建议拿到板子后写一个小测试程序，把你要用的源格式到目标格式的每一种组合都跑一遍，确保稳定后再写进正式代码。

第三个经验，小尺寸图像没必要用RGA。RGA的优势在分辨率高的场景，如果你的图像只有320x240，CPU处理也就1毫秒以内，专门调RGA反而有函数调用和驱动开销，性能提升不明显。我一般以512x512作为分界线，大于这个尺寸才考虑RGA。

第四个经验，注意多次RGA操作之间的buffer生命周期。如果你用的是临时buffer，比如malloc出来的虚拟地址，RGA返回后就不能再动了；如果复用同一个buffer，下一次调用前要确保上一次操作已经完成。IM2D同步接口帮我们省了这一步，但一旦改成异步模式或者多线程共享buffer，这条特别容易出问题。

6. 再往前一步：RGA和USB摄像头RTSP推流的组合

还有一个常见的需求是USB摄像头转RTSP流。USB摄像头插上RK3588，v4l2节点拿到的是YUYV或者MJPEG，推流编码前需要转成NV12，同时统一分辨率。

我之前写的处理链路是：v4l2读帧 -> RGA转NV12 -> 设置编码器输入 -> 硬编H.264/H.265 -> 推RTSP。RGA在这个链路里承担的是格式转换和缩放，整个推流过程CPU占用在单路场景下几乎为0。

这里有个小技巧：v4l2读出来的buffer通常是v4l2_buffer，里面带长度和offset，但不一定是连续dma buffer，如果直接用虚拟地址转，要注意V4L2的缓冲可能带有padding。我在代码里用mmap映射后，读取了v4l2_format里的bytesperline，换算成RGA的wstride，问题就解决了。

整条推流链路调通之后，延迟大约在100到200毫秒之间，画质清晰，CPU占用不到5%，这是纯软件转码方案完全做不到的。

我个人在实际项目里的选择是：所有涉及大尺寸图像格式转换和缩放的地方，无脑切RGA，只有小图操作和不可控的第三方库才保留CPU路径。这几个月下来，踩过格式不对的坑，也排过stride对齐的错，但一旦把这些基础问题解决掉，RGA带来的性能和稳定性收益是非常确定的。希望这篇实战记录能让你在RK3588上少走几步弯路。