1. RK3588图像缩放为什么值得折腾GPU加速1.1 一个真实项目场景四路4K视频把CPU吃满之后前阵子在RK3588板卡上做多路视频处理项目硬件平台是标准工规板8核CPU看起来资源很充裕。结果一接入四路4K摄像头每路都要做缩放、裁剪、格式转换然后把画面分别送往显示通道和算法推理通道。最初版本全部用OpenCV的cv::resize在CPU上跑测试一压测CPU占用直接飙到60%以上解码线程和推理线程开始抢资源画面出现肉眼可见的卡顿帧率从稳定的25fps掉到17fps左右。当时第一反应是上GPU加速。RK3588这颗芯片集成了Mali-G610 MP4 GPU在OpenCL 2.0的支持下理论上可以分担图像处理负载。而且OpenCV从3.x开始就对OpenCL后端有完整的封装代码层面只需要把cv::Mat换成cv::UMat就能把图像缩放等算子调度到GPU上执行迁移成本看起来并不高。但实际的坑比想象中多——OpenCL平台识别不到、编译选项没开全、某些插值算法在GPU后端根本没有实现、小分辨率图像在GPU上反而更慢。这些问题是官方文档很少写清楚的也是我在这篇博文里要重点展开的内容。如果你正准备在RK3588或者其他ARM Linux板卡上做OpenCV图像缩放加速这篇实测记录应该能帮你少走不少弯路。1.2 Mali-G610的OpenCL能力与CPU缩放瓶颈分析RK3588的GPU是Mali-G610 MP4属于高通的Adreno、ARM的Mali这一路移动端GPU架构。OpenCL支持情况由Rockchip提供的用户态驱动libmali决定在Ubuntu和Debian系统上通常可以获得OpenCL 2.0的完整能力。但这里有个关键前提系统里必须安装并且正确加载libOpenCL.so同时OpenCV编译时必须显式开启WITH_OPENCL否则就算硬件支持代码里cv::ocl::haveOpenCL()也会返回false。为什么CPU缩放在高分辨率下会成为瓶颈原理上cv::resize是逐像素计算的过程假设把3840x2160的4K图像缩放到1920x1080双线性插值每个目标像素需要做4次乘法、2次加法、若干次边界判断和数据访问。以A76核心的IPC每时钟周期指令数来计算单核跑完大约需要15到25毫秒四路视频串行处理就是60到100毫秒这还没算上多线程调度和缓存抖动的影响。GPU的并行优势在于它有成百上千个ALU单元图像缩放这种像素级独立的计算任务天然适合大规模并行。Mali-G610的浮点算力虽然比不上桌面独显但在1080p到4K这个级别的图像缩放场景里理论上可以把延迟压到个位数毫秒级。实测下来也确实如此——4K缩放到1080p双线性插值在GPU上能做到约CPU三分之一甚至更短的耗时。但要注意这个加速比有严格的前提条件后面第4章和第5章会详细展开。1.3 CPU、NEON与OpenCL三条路线怎么选在ARM Linux平台上做图像缩放实际上有三条路线纯CPUOpenCV默认实现、NEON优化ARM的SIMD指令集、GPUOpenCL。NEON优化本质上还是CPU在算但利用了ARM的向量指令一次处理多个像素性能通常能比普通C实现快2到4倍。OpenCL则是把计算真正搬到GPU上。我的建议是先想清楚你的瓶颈在哪里。如果只是单路1080p缩放NEON优化已经完全够用上GPU反而因为数据传输开销得不偿失。如果是多路4K视频、或者需要缩放的同时还要做颜色转换、滤波等一系列操作GPU的综合优势就会非常明显——因为这些操作可以全部在GPU端链式完成避免多次CPU与GPU之间的数据往返。如果你项目里已经用上了Rockchip的MPPMedia Process Platform做硬解码那么还有一个额外的选择是RGA硬件缩放。RGA是RK3588内部的2D图形加速单元专门做格式转换、缩放、旋转性能比OpenCL的通用计算路径更快。但RGA需要单独封装且接口和OpenCV不通用。所以从工程效率和代码可维护性的角度我最终选择了OpenCV的OpenCL后端作为主力方案这也是本文实测的重点。2. 5种插值算法的工作机制与选型逻辑2.1 插值的本质缩放时新像素怎么算出来图像缩放不是简单的像素复制或删除因为目标图像的像素网格和源图像通常不对齐。比如把1920宽缩到1280宽目标像素每前进一个单位对应源图像位置是1.5个像素。这个1.5落在两个源像素之间就需要通过某种规则算出一个合理值。这个算的规则就是插值算法。不同算法的区别主要体现在两个方面参与计算的源像素范围有多大以及如何给这些像素分配权重。OpenCV提供了超过5种插值算法但日常项目里最常用的就是INTER_NEAREST、INTER_LINEAR、INTER_CUBIC、INTER_AREA和INTER_LANCZOS4这五种它们恰好覆盖了从最快到最精细的整个需求光谱。我在RK3588上分别验证了这5种算法在CPU和GPU两种路径下的实际表现结论是没有任何一种算法在所有场景下都是最优解。选错算法有时比选错加速方式更伤性能比如在GPU上跑INTER_LANCZOS4某些分辨率组合下甚至比CPU还慢。2.2 逐个拆解5种算法的原理与适用场景INTER_NEAREST最近邻插值直接取距离目标位置最近的源像素值。计算量最小边缘呈明显锯齿状放大像素风图片时反而有独特效果。适合极低功耗场景、图像缩略图预览、以及缩放倍数接近整数的场景。在GPU上这种算法几乎不占什么计算资源。INTER_LINEAR双线性插值取目标位置周围2x2邻域的源像素按距离做两次线性加权。OpenCV的默认算法也是工程上最推荐的平衡点——质量尚可、速度快、硬件支持最完善。在RK3588的GPU后端双线性插值的内核优化得最好实测加速效果最稳定。INTER_CUBIC双三次插值取4x4邻域用三次多项式函数计算权重。相比双线性边缘更平滑、细节保留更好但计算量约是双线性的4到8倍。适合图像放大后需要人工观看的场景比如数码头放大截图、医学影像查看。代价是裁剪区域可能产生轻微振铃效应ringing也就是在强边缘附近出现亮暗交替的伪轮廓。INTER_AREA区域插值这个算法比较特殊它基于像素面积的重采样关系。缩小时它等价于对源图像局部区域求平均防混叠效果极好放大时它退化为双线性插值。工程上有个隐蔽坑很多人不知道INTER_AREA在OpenCV的OpenCL后端是不一定被优化的实测中它有时会被悄悄回退到CPU执行。INTER_LANCZOS4Lanczos插值使用基于sinc函数的Lanczos核邻域范围扩大到8x8。这是所有算法里细节还原最精确的但计算量也非常大且振铃效应比双三次更明显。在GPU上虽然能加速但加速比通常不如双线性和双三次那么高。2.3 选型逻辑不要无脑用INTER_LINEAR我见过很多项目代码里所有缩放操作全部用INTER_LINEAR省事是省事但不是最优选择。根据我的实测经验选型可以按这个逻辑来判断使用场景推荐算法原因视频监控画面上屏、实时预览INTER_LINEAR速度与质量平衡GPU加速表现最好大图缩小为缩略图INTER_AREA防混叠效果好纹理不闪烁图像放大供人工仔细查看INTER_CUBIC 或 INTER_LANCZOS4细节保留好边缘更平滑极速处理、低功耗场景INTER_NEAREST计算量最小GPU上几乎无压力高分倍数缩小INTER_AREA局部均值等效于低通滤波有效抑制噪点被缩小后聚集有个很容易被忽略的判断维度是缩放倍数。当你把一张4K图缩小到128x128这种极小尺寸时INTER_LINEAR会产生明显的摩尔纹和锯齿而INTER_AREA的表现要好得多。反过来如果你的需求是逐像素精度比如在算法预处理里把224x224的图放大到448x448INTER_LINEAR就完全够用INTER_CUBIC带来的质量提升肉眼很难分辨白白浪费算力。在实际项目中我现在的做法是封装一个smartResize函数缩小时默认走INTER_AREA放大时根据目标尺寸和性能预算决定用INTER_LINEAR还是INTER_CUBIC并保留一个全局开关允许上层业务覆盖这个默认逻辑。这样既保证了画面质量又给了业务侧足够的灵活性。3. 环境搭建为OpenCV启用OpenCL后端的完整流程3.1 确认RK3588系统里的OpenCL驱动链在RK3588的Linux系统上OpenCL的软件栈分为三层GPU硬件Mali-G610、内核态驱动通常已经编入内核或作为模块加载、用户态驱动libmali。用户态驱动通过ICDInstallable Client Driver机制向OpenCL应用暴露能力。OpenCV或者clinfo这类工具在启动时会通过libOpenCL.so去读取/etc/OpenCL/vendors/目录下的.icd文件从而找到具体的Mali驱动实现。所以你首先要确认三件事系统里有没有libOpenCL.so这个loader库通常由ocl-icd-opencl-dev这个包提供。/etc/OpenCL/vendors/目录下有没有类似mali.icd的文件文件内容一般是libmali.so的绝对路径。libmali.so本身是否存在以及它的依赖是否完整。我遇到过一种情况板子上有libOpenCL.so也能正常加载但/etc/OpenCL/vendors/目录是空的导致所有OpenCL应用都找不到平台。这种问题在精简版固件上尤其常见网上很多教程默认你用的是Rockchip官方完整固件但实际上很多定制系统把ICD文件给精简掉了。检查方法很简单安装clinfo后运行sudo apt install clinfo clinfo如果能看到类似Mali-G610的platform名称说明OpenCL链路是通的。如果报错Number of platforms: 0那就不用往后看了——OpenCV编译得再正确运行时也找不到GPU。3.2 编译OpenCV时的CMake选项清单RK3588上多数预编译的OpenCV包并没有开启OpenCL后端因为要兼容各种ARM设备。所以想用到GPU加速最好自己编译一遍。以下是我验证过可用的CMake配置git clone https://github.com/opencv/opencv.git cd opencv git checkout 4.9.0 mkdir build cd build cmake -D CMAKE_BUILD_TYPERelease \ -D CMAKE_INSTALL_PREFIX/usr/local/opencv-cl \ -D WITH_OPENCLON \ -D WITH_OPENCLAMDBLASON \ -D WITH_OPENCLAMDFFTON \ -D WITH_GTKOFF \ -D WITH_OPENMPON \ -D BUILD_TESTSOFF \ -D BUILD_PERF_TESTSOFF \ -D BUILD_EXAMPLESOFF \ -D OPENCV_ENABLE_NONFREEON ..几个关键选项说明一下WITH_OPENCLON是总开关不开这个后面全白搭。WITH_OPENCLAMDBLAS和WITH_OPENCLAMDFFT是OpenCL加速的BLAS和FFT库支持虽然图像缩放用不太上但如果你后续要做矩阵运算或频域处理建议还是开着。WITH_OPENMPON是让OpenCV在CPU路径上也能用多线程这在GPU不可用时会作为兜底方案。CMAKE_INSTALL_PREFIX设成独立目录避免和系统自带的OpenCV冲突这一点在RK3588这种板卡上非常重要——你不想因为换掉系统OpenCV导致其他依赖它的程序崩溃。编译过程没什么特别的RK3588的8核CPU大约20分钟左右能编完。编译后别忘了把/usr/local/opencv-cl/lib加入LD_LIBRARY_PATHecho export LD_LIBRARY_PATH/usr/local/opencv-cl/lib:$LD_LIBRARY_PATH ~/.bashrc source ~/.bashrc3.3 用一小段代码验证OpenCL是否真的接管了计算环境装好后不能只看clinfo的结果还要确认OpenCV内部的OpenCL上下文确实初始化成功。写一个小测试程序#include opencv2/opencv.hpp #include iostream int main() { cv::ocl::setUseOpenCL(true); if (!cv::ocl::haveOpenCL()) { std::cout OpenCL is NOT available std::endl; return -1; } cv::ocl::Device dev cv::ocl::Device::getDefault(); std::cout OpenCL device: dev.name() std::endl; std::cout OpenCL version: dev.OpenCL_Version() std::endl; // 构造一张1080p图用UMat走GPU缩放 cv::Mat src(1080, 1920, CV_8UC3, cv::Scalar(128, 128, 128)); cv::UMat uSrc src.getUMat(cv::ACCESS_READ); cv::UMat uDst; cv::resize(uSrc, uDst, cv::Size(640, 360), 0, 0, cv::INTER_LINEAR); std::cout Resize done, result empty? uDst.empty() std::endl; return 0; }如果输出里能看到Mali-G610的设备名且resize正常执行说明OpenCL后端已经生效。这里有个小技巧在OpenCV的调试模式下设置环境变量OPENCV_OPENCL_DEVICEGPU可以强制指定设备而OPENCV_OPENCL_RUNTIME可以指定运行时版本排查问题时特别好用。4. 实测方案与结果CPU与GPU的对比数据4.1 测试方法说明这次实测我尽量做到公平和可复现。硬件平台是某款基于RK3588的标准工控板运行Ubuntu 22.04内核5.10系统安装了Rockchip官方libmali驱动。软件环境是OpenCV 4.9.0按第3章的配置编译。测试分两组CPU路径cv::Mat 默认后端和GPU路径cv::UMat OpenCL。每组测试三种输入分辨率1920x10801080p、3840x21604K、7680x43208K分别缩放到720p、1080p、2160p。每种算法跑100次取平均耗时前10次作为warm-up不计入统计。单位统一为毫秒。测试代码如下cv::Mat src imread(argv[1]); cv::Size dstSize(1280, 720); // CPU路径 cv::Mat dstCpu; auto t0 std::chrono::high_resolution_clock::now(); cv::resize(src, dstCpu, dstSize, 0, 0, interp); auto t1 std::chrono::high_resolution_clock::now(); // GPU路径 cv::UMat uSrc src.getUMat(cv::ACCESS_READ); cv::UMat uDst; auto t2 std::chrono::high_resolution_clock::now(); cv::resize(uSrc, uDst, dstSize, 0, 0, interp); cv::ocl::finish(); auto t3 std::chrono::high_resolution_clock::now();注意GPU路径在计时结束后加了一次cv::ocl::finish()这是为了保证GPU队列里的异步操作真正执行完。如果不加计时会严重偏小得出的加速效果是假的。4.2 实测数据5种算法在CPU与GPU上的耗时对比这里我选取几组有代表性的数据完整数据太多篇幅限制只列关键几项算法输入分辨率输出分辨率CPU耗时(ms)GPU耗时(ms)加速比INTER_NEAREST1920x10801280x7203.22.81.14xINTER_LINEAR1920x10801280x7208.76.51.34xINTER_CUBIC1920x10801280x72031.518.21.73xINTER_AREA1920x10801280x72022.821.41.07xINTER_LANCZOS41920x10801280x72078.342.91.83xINTER_LINEAR3840x21601920x108033.213.62.44xINTER_CUBIC3840x21601920x1080128.547.92.68xINTER_AREA3840x21601920x108089.463.51.41xINTER_LANCZOS43840x21601920x1080293.7115.22.55xINTER_LINEAR7680x43203840x2160132.648.42.74xINTER_LANCZOS47680x43203840x21601182.5421.32.81x4.3 数据背后的三个规律看完整组数据有三个规律值得展开说。第一分辨率越大GPU加速效果越明显。1080p缩到720p加速比只有1.1到1.8倍4K缩到1080p加速比提升到1.4到2.7倍8K缩到4K时INTER_LANCZOS4依然能保持接近3倍的加速。原因很直观——GPU的kernel启动开销和host-device数据拷贝开销是相对固定的当计算量大到能覆盖这些固定开销后并行计算的优势才能充分体现。第二计算越复杂的算法GPU加速比越高。INTER_NEAREST在GPU上几乎没有优势因为它太简单了GPU的并行能力还没完全发挥就结束了。INTER_LANCZOS4和INTER_CUBIC这种计算密集型算法反而是GPU收益最大的。这给了我们一个启示如果你的业务场景用的是双三次或Lanczos插值上GPU的回报是最高的如果只是最近邻那还不如直接在CPU上跑省去UMat转换和数据拷贝的麻烦。第三INTER_AREA在GPU后端的表现比较特殊。它的加速比明显低于其他算法4K场景只有1.41倍。我后来进一步排查发现OpenCV的OpenCL后端对INTER_AREA的实现路径和CPU版本不同在某些条件下甚至会出现cv::resize内部的OpenCL kernel抛异常、自动回退到CPU执行的情况。这个问题后面避坑部分会详细讲。5. 你会踩到的坑UMat、数据拷贝与OpenCL平台发现5.1 坑一clinfo能看到GPU但OpenCV就是识别不到这个坑我在第3章提过但因为它太典型了值得再加深一下印象。现象是命令行里clinfo能正常列出Mali-G610但跑OpenCV程序时cv::ocl::haveOpenCL()返回false或者cv::ocl::Device::getDefault()报错。排查链路可以按这个顺序走检查程序链接的OpenCL库。ldd 你的程序看是不是链接到了系统自带的libOpenCL.so.1而不是/etc/OpenCL/vendors/里指定的libmali.so。有时候系统同时装了两套OpenCL实现loader会选择错误的那个。设置OpenCV的调试输出。在程序开头加cv::utils::logging::setLogLevel(cv::utils::logging::LOG_LEVEL_DEBUG);OpenCV会打印OpenCL上下文初始化的详细日志包括加载了哪个ICD文件、为什么失败。检查环境变量。OPENCV_OPENCL_DEVICE和OPENCV_OPENCL_RUNTIME这两个变量可能被设置成了无效值。手动写一个OpenCL探测程序。不通过OpenCV直接用clGetPlatformIDs和clGetDeviceIDs查询确认底层链路没问题。我遇到的情况最后定位到程序用sudo运行时LD_LIBRARY_PATH被重置导致libOpenCL.so找不到/usr/local/opencv-cl/lib下的依赖初始化静默失败。加上sudo -E保留环境变量就解决了。5.2 坑二UMat的异步执行导致性能统计严重失真如果你是第一次用cv::UMat几乎一定会犯这个错误——以为cv::resize调用返回就代表计算完成直接开始计时。实际上OpenCV的OpenCL后端默认是异步执行的函数调用只是把kernel排队到GPU命令队列里真正的计算还没开始。如果你的下一段代码只是读取GPU结果比如调用uDst.getMat(cv::ACCESS_READ)OpenCV会隐式地做一次设备到主机的数据同步这时才会真正等待GPU执行完毕。所以性能测试代码必须显式调用cv::ocl::finish()它等价于clFinish确保队列清空。我最初测试时漏掉了这一步统计出的GPU耗时比真实值少了30%到50%差点得出GPU加速无敌的错误结论。把finish加上后4K缩1080p的耗时从9.7ms变成了13.6ms差距非常大。5.3 坑三小图像在GPU上反而更慢阈值到底在哪这个现象在1080p级别已经很轻微了但在640x480以下非常明显。原因主要是两部分开销数据上传开销cv::Mat转cv::UMat时OpenCV要把主机内存的数据拷贝到GPU可访问的内存通常是设备内存或统一内存这个拷贝本身有固定延迟。kernel启动开销GPU执行一个kernel需要经历创建上下文、编译程序、设置参数、入队、执行等多个步骤虽然OpenCV会在内部缓存这些对象但首次调用的延迟依然有几百微秒到几毫秒。实测下来在我的环境里大约在输入图像面积小于等于640x480时GPU路径的耗时开始超过CPU路径。如果你要处理的全是小图老老实实用CPU就好不用折腾OpenCL。如果你需要大小图混合处理我建议在封装层做一个自动分流cv::UMat smartResizeToUMat(const cv::Mat src, cv::Size dstSize, int interp) { if (src.cols * src.rows 640 * 480) { cv::Mat dst; cv::resize(src, dst, dstSize, 0, 0, interp); return dst.getUMat(cv::ACCESS_READ); } cv::UMat uSrc src.getUMat(cv::ACCESS_READ); cv::UMat uDst; cv::resize(uSrc, uDst, dstSize, 0, 0, interp); return uDst; }5.4 坑四部分插值算法在OpenCL后端并未全量实现这是一个容易被忽视的大坑。我最初测试时用的是自定义函数自动遍历5种插值算法结果程序在INTER_AREA上直接崩溃报错信息指向OpenCL kernel编译失败。后来查阅OpenCV源码发现在ocl_kernel目录下INTER_LANCZOS4和INTER_AREA的内核实现是有条件编译的某些设备特性不满足时会被跳过。更隐蔽的是即使kernel存在OpenCV 4.x在某些版本下对INTER_AREA在GPU端的行为做了特殊处理——当缩放比例小于某个阈值时它会退化为INTER_LINEAR导致输出结果和CPU路径不一致。如果你在做一个需要像素级一致性校验的项目比如算法评测、基准测试这个差异会直接影响结论。解决方案有两个一是严格限定你使用的插值算法集合在调用cv::resize前先检查cv::ocl::Device::isExtensionSupported(cl_khr_fp16)等特性确认当前设备支持二是在需要确保行为一致时对特定算法强制走CPU路径。没有万金油的方案只有根据业务需求权衡。6. 加速效果的边界在哪里与部署建议6.1 一个决定性因素数据在CPU和GPU之间来回拷贝UMat看着用起来方便但它的内存管理策略是懒加载的。当你把cv::Mat转成cv::UMat时OpenCV并不立即拷贝数据而是等到实际执行kernel前才做一次性上传。反过来读完GPU结果后你通常要调getMat()把数据下载回主机内存。这两次拷贝在高分辨率图像上非常昂贵。我特意做了一个实验只测一次Mat - UMat 一次UMat - Mat的开销不执行任何算法。结果是输入分辨率单次上传下载耗时(ms)1920x10802.33840x21608.97680x432035.7这意味着8K图像缩放即使GPU计算只要48ms算上数据搬运总延迟反而接近85ms。所以在设计系统时一定要想办法把多次图像操作合并到GPU侧完成比如缩放颜色转换边缘检测这三个操作如果全部用UMat链式执行数据只需要上传一次、下载一次效率远超分别操作三次。6.2 多路视频并发场景下的GPU占用与收益前面测的是单张图像的延迟但在真实项目里多路视频并发才是常态。四路4K视频同时缩放CPU路径下四路完全串行总耗时约130msGPU路径下四路的resize kernel可以排进同一条命令队列GPU硬件调度器会自动交错执行总耗时约55ms平均每路不到14ms。这个加速比约2.4倍看起来不算夸张但关键在于CPU被释放出来了——解码线程、推理线程不再被缩放任务挤占系统整体帧率明显上升观察CPU占用率从60%降到了18%。不过GPU资源不是无限的。Mali-G610的算力在同时处理多路8K缩放时会出现瓶颈再叠加渲染或推理任务就容易拖慢整个Pipeline。建议在实际应用中给GPU资源占用设定一个水位线比如用cv::ocl::Device::getDefault().maxComputeUnits()和当前队列任务数做一个简单的估算当GPU侧排队任务超过阈值时部分非关键路径的缩放自动切回CPU执行。6.3 我的最终部署方案混合调度策略经过这一轮实测和踩坑我在RK3588项目里的最终方案是这样的单路1080p以下纯CPU INTER_LINEAR不折腾。单路4K及以上GPU INTER_LINEAR或INTER_CUBIC根据画质要求选择。多路视频每路先判断输入分辨率超过阈值的走GPU小图走CPU用线程池并行调度。缩略图场景固定用INTER_AREA但是设定标记强制走CPU路径避免OpenCL后端的执行路径不一致导致画面质量波动。算法链路合并如果缩放后面紧跟颜色转换或其他像素级操作用UMat链式传递尽量减少数据往返次数。另外我还发现一个实用的组合GPU缩放 CPU格式转换。解码器输出的通常是NV12格式OpenCV的cvtColor在OpenCL后端对NV12的支持不太好但缩放本身挺好用。所以我的做法是先用RGA或CPU把NV12转成BGR再用GPU做缩放。两种分工各取所长整体效果比全链路都塞给OpenCL要好。6.4 RK3588特有的其他加速路径RGA的定位如果你手里的项目对延迟极度敏感而且缩放格式相对固定RGA值得关注。RK3588的RGA是一个独立的2D硬件加速模块专门做缩放、格式转换、旋转。有一次我实测把1080p缩放成720p并转成NV12RGA的端到端耗时只有0.8ms左右远低于OpenCL的6.5ms。但RGA的接口是Rockchip私有API不像OpenCV那样跨平台代码耦合度也高。我的建议是产品原型阶段先用OpenCV OpenCL方案快速跑通等性能瓶颈和功能边界都摸清楚了再把热点路径替换成RGA定制实现。结合这轮实测的经验我对RK3588这个平台做图像缩放加速的总体判断是GPU加速不是银弹但有明确的适用边界。对于4K以上分辨率和复杂插值算法它的收益非常可观对于小图和极简算法反而可能拖慢系统。把数据搬运成本、算法特点、并发模型都考虑进去后再决定哪些路径走GPU哪些留在CPU才能真正释放这块板子的性能。后面如果再深入的话我打算把RGA和OpenCL做一个更系统的横向对比并在多路并发场景下压测内存带宽的占用到时候再出一篇补充实测。