RK3588 VPU 与 NPU 硬件加速基准测试

本项目用于定量测试 RK3588 平台的三项核心能力：

1. MPP 视频编码能力
2. MPP 视频解码能力
3. RKNN 推理能力

测试范围：

• 编码：NV12 -> MJPG / H.264 / H.265
• 解码：MJPG -> YUV420
• 推理：640x640 输入的 YOLOv8n / YOLOv8s / YOLOv8m
• 分辨率：720p / 1080p / 2K / 4K / 8K

#RK3588 基准测试汇总

• 生成时间：2026-09-20 17:09:50
• 编解码帧数：预热 20 帧 + 测量 120 帧
• 推理帧数：预热 20 帧 + 测量 200 帧
• CPU governor：ondemand
• 测试前后温度：约 35–36°C / 36–37°C

#视频编码测试（NV12 -> MJPG / H.264 / H.265）

#视频解码测试（MJPG -> YUV420）

#YOLOv8 640x640 推理测试

#1. 运行基准测试项目

请在 reComputer RK3588 板端运行。

sudo apt update && sudo apt install unzip -y
wget https://files.seeedstudio.com/RK3576/rk3588_mpp_benchmark_install.zip -O install.zip && unzip install.zip
cd ./install && export LD_LIBRARY_PATH="$(pwd)/lib:${LD_LIBRARY_PATH}" && chmod +x ./bin/rk3588_benchmark
sudo ./bin/rk3588_benchmark

测试结果保存在：

ls ./benchmark_results
benchmark_summary.md  video_codec_benchmark.csv  yolov8_inference_benchmark.csv

常用参数：

./bin/rk3588_benchmark \
  --output-dir ./benchmark_results \
  --resolutions 720p,1080p,2k,4k,8k \
  --models yolov8n,yolov8s,yolov8m \
  --codec-warmup 20 \
  --codec-frames 120 \
  --infer-warmup 20 \
  --infer-frames 200

包装脚本会将 LD_LIBRARY_PATH 指向安装包内的 lib/。如果当前用户无权访问 /dev/mpp_service 或 /dev/rga，脚本会通过 sudo 重新运行。

#2. 项目能力

工程自动生成测试帧，执行多分辨率编码、MJPG 硬解和 640x640 YOLOv8 推理测试，并输出 Markdown 总结与 CSV 原始数据。

#3. 测试流程

1. 按指定分辨率生成动态 YUV420SP (NV12) 帧。
2. 分别运行 MPP 的 MJPG、H.264 和 H.265 编码器。
3. 保留生成的 MJPG 裸码流，通过 MPP advanced task API 解码为 YUV420。
4. 生成 640x640 NV12 帧并通过 RGA 预处理。
5. 运行针对 RK3588 转换的 YOLOv8n/s/m RKNN 模型。
6. 汇总 FPS、平均延迟、P95 延迟和输出大小。
7. 生成 Markdown 与 CSV 报告。

#4. 技术方案

#4.1 编码

编码器基于 Rockchip MPP，输入为动态生成的 YUV420SP (NV12)。MJPG 使用 Q=80，H.264/H.265 使用结果表中的 CBR 码率。每组预热 20 帧、测量 120 帧。

• Pure FPS：测量帧数除以 MPP encode_put_frame 和 encode_get_packet 的累计调用时间
• Pipeline FPS：完整循环吞吐率，包含帧生成、输入写入和输出复制
• Pure Avg/P95：MPP 测量区间的单帧平均与 P95 延迟
• Output：120 个测量帧的编码输出总大小

Pure FPS 是串行提交下的服务速率，不包含 CPU 准备下一帧时 VPU 可能产生的空闲，因此不是摄像头、网络、显示或存储完整链路的最终帧率。

#4.2 解码

解码器复用各分辨率的 MJPG 码流，通过 RK3588 MPP advanced task API 执行 MJPG -> YUV420。每组同样预热 20 帧、测量 120 帧。

• Pure Decode FPS：从完成压缩包分配和复制后开始计时，直到 MPP 返回输出帧
• Pipeline FPS：还包含压缩包准备和 task 回收

#4.3 推理

推理路径生成 640x640 NV12 帧，经 RGA 预处理后送入 RKNN Runtime，测试以下模型：

• yolov8n_rk3588.rknn
• yolov8s_rk3588.rknn
• yolov8m_rk3588.rknn

每个模型预热 20 帧、测量 200 帧。报告分别记录完整 Infer、RGA 预处理和 RKNN 推理阶段的延迟。

#5. 结果指标说明

#5.1 编码结果

使用 Pure FPS 比较 VPU 服务能力，使用 Pipeline FPS 评估未经优化的完整循环。两者差距可以反映帧生成和内存复制对结果的影响。

#5.2 解码结果

Pure Avg/P95 和 Pure FPS 描述完成压缩包准备后的硬件解码区间，Pipeline FPS 则覆盖完整的压缩包处理循环。

#5.3 推理结果

Inference FPS 来自完整的串行 Infer 调用；Preprocess 单独统计 RGA；NPU 统计 RKNN 推理阶段。摄像头采集、网络、显示和应用队列不在其中。

#6. 基于当前结果的客观评估

排除 CPU 侧 NV12 合成、输入内存写入和输出复制后，RK3588 的 4K H.264/H.265 纯编码约为 64 FPS，4K MJPG 纯解码为 106.1 FPS，YOLOv8n 推理为 33.9 FPS。较低的端到端编码数字主要反映本测试 Pipeline 的帧准备和内存搬运，而不是 VPU 单元本身。虽然 8K H.265 纯编码达到 32.4 FPS，完整循环只有 18.2 FPS；持续的端到端 8K@30 仍需要零拷贝、并行提交以及完整媒体链路优化。

#7. 推荐部署策略

1. 实时检测默认使用 YOLOv8n；YOLOv8s/m 应配合抽帧和有界队列，避免延迟持续累积。
2. 生产环境的 4K H.264/H.265 链路应使用零拷贝或共享采集缓冲，并为其他负载预留内存带宽。
3. 不要根据 32.4 Pure FPS 宣称端到端 8K@30，当前 Pipeline 只有 18.2 FPS。
4. 8K MJPG 解码的 P95 已超过 30 FPS 单帧间隔，工程中应保留余量。
5. 发布正式性能数据前，建议按需固定时钟、至少运行三轮，并报告中位数、P95 和温度。