全志T113-i开发板G2D硬件加速实战：YUV转RGB性能优化与对比

1. 为什么你需要关心T113-i的G2D硬件加速？

如果你正在用全志T113-i这类嵌入式芯片做图像相关的项目，比如做个小相机、智能门铃，或者想在屏幕上流畅地显示视频，那你大概率会遇到一个头疼的问题：图像格式转换太慢了。尤其是从摄像头或者视频流里出来的YUV数据，要变成屏幕能显示的RGB，这个计算量可不小。纯靠CPU吭哧吭哧地算，画面刷新率上不去不说，CPU占用率还高得吓人，其他任务就别想跑了。

我刚开始在米尔MYD-YT113i开发板上折腾的时候，就踩过这个坑。一个简单的1080p视频预览，用C语言写的YUV转RGB，CPU直接飙到快100%，画面还一顿一顿的。这显然不行啊，T113-i这颗双核A7虽然能干，但也不能把所有力气都花在搬砖上。这时候，硬件加速就该登场了。

全志T113-i内部集成了一个叫G2D的2D图形加速硬件。简单来说，它就是个专门处理图像“搬砖”和“变形”的“小工头”。像颜色空间转换（YUV转RGB）、图像缩放、旋转、叠加这些脏活累活，它都能帮你干了，而且干得飞快，最关键的是，它不占用CPU核心的计算资源。CPU只需要发个指令：“小工头，把这堆YUV砖头搬到那边，砌成RGB的样子”，然后就可以去喝茶了，剩下的G2D全包。

所以，这篇文章就是一次实打实的“性能压榨”之旅。我会带你一起，在T113-i开发板上，用三种不同的方法来实现YUV到RGB的转换：最基础的C语言实现、用ARM NEON指令集手动优化、最后祭出大杀器——G2D硬件加速。我们会一行行写代码，一步步测性能，看看这个“小工头”到底有多能打，以及它最适合在什么场景下出场。无论你是刚接触嵌入式图像处理的萌新，还是正在为性能发愁的老手，相信这篇实战记录都能给你带来一些直接的帮助和启发。

2. 动手之前：认识你的开发板和G2D

工欲善其事，必先利其器。在开始写代码之前，我们得先搞清楚手头的家伙事儿到底有多大能耐。

我用的这块米尔MYD-YT113i开发板，核心是全志T113-i处理器。它有两个Cortex-A7核心，主频1.2GHz，还附带一个RISC-V协处理器和HiFi4 DSP，接口非常丰富，从摄像头、显示屏到千兆网、CAN总线都有，是个很适合做多媒体和物联网终端的小钢炮。更重要的是，它内置了视频编解码器和我们今天的主角——G2D硬件。

那么，这个G2D具体能干啥呢？根据全志官方的资料，它的能力清单相当豪华：

• 支持大画面：最大能处理2048x2048像素的图层。
• 格式转换：支持多种YUV格式（4:2:0, 4:2:2, 4:1:1）和像素格式（8/16/24/32位）之间的任意转换。我们今天的YUV转RGB就是它的核心功能之一。
• 缩放与抗锯齿：支持1/16倍到32倍的缩放，还有高质量的抗锯齿滤波器。
• 图像操作：填充矩形、位块传输（BitBlit）、拉伸传输、旋转、水平/垂直翻转，都不在话下。
• 图层混合：支持两个图层的Alpha混合，做UI叠加、水印非常方便。

简单理解，G2D就是一个专为2D图像操作设计的“流水线工厂”，CPU把原料（源图像）和图纸（操作命令）送进去，它就能高效地生产出成品（目标图像）。它的存在，就是为了把CPU从繁重的像素计算中解放出来。

我们的目标很明确：让这个“工厂”来帮我们做YUV420SP（一种常见的YUV排列格式，比如很多摄像头输出的NV21/NV12）到RGB888的转换。为了对比，我们还会准备两个“手工”方案：纯C语言和ARM NEON优化，看看“工厂”的效率到底比“手工”高多少。

3. 搭建开发环境与准备“工具箱”

在开始性能对决之前，我们得先把擂台搭好，工具备齐。整个过程其实不复杂，跟着我一步步来就行。

基础环境搭建：这部分米尔电子的资料很全，假设你已经按照官方教程，在Ubuntu主机上配置好了交叉编译工具链（比如 arm-linux-gnueabihf-），并且能够通过网络或SD卡将程序部署到开发板上运行。如果还没搞定，可以搜一下“米尔T113-i开发环境配置”，有很多详细的帖子。

关键的头文件与驱动：要操作G2D硬件，我们不需要链接复杂的动态库，Linux内核已经为我们提供了标准的设备驱动接口。我们只需要通过 ioctl 系统调用来“对话”即可。这就需要几个关键的头文件，它们定义了“对话”所需的“语言”（数据结构）：

1. g2d_driver.h：这里面定义了所有G2D操作命令和参数结构体，比如我们后面会用到的 g2d_blt_h、g2d_image_h 等。你可以从米尔或全志提供的SDK框架里找到它。
2. DmaIon.h：这是另一个重点。G2D硬件操作的是物理地址连续的内存（DMA缓冲区），而我们在用户态用 malloc 分配的内存是虚拟的、可能物理上不连续。所以我们需要通过 ion 内存分配器来申请一种特殊的、能被GPU、视频编解码器、G2D等硬件直接访问的内存。这个头文件就包含了操作 ion 缓冲区的相关定义。

我的建议是，直接去米尔在GitHub上开源的框架仓库里，把这两个头文件以及相关的示例代码（比如 DmaIon.cpp）下载下来，放到你的项目目录里。这是最稳妥的方式，能避免因版本差异导致的编译错误。

测试工具：opencv-mobile：为了验证我们转换的结果是否正确（颜色对不对），我们需要一个可靠的参照物。这里我推荐使用 opencv-mobile。它是一个高度精简优化的OpenCV库，特别适合嵌入式平台。我们不需要它的全部功能，只用它来加载一张JPEG图片（它会解码成BGR格式），然后我们把图片转换成YUV420SP格式，再用我们的三种方法转回RGB，最后用opencv-mobile保存成图片，用眼睛或者工具对比一下，就能知道转换是否成功了。编译和移植opencv-mob