手上接到过不少RK3588的项目但真正让我觉得有代表性的还是这块创龙的国产工业开发板。不是因为它参数多好看而是从交叉编译到GPU渲染整条链路做下来的那种踩坑与打通的过程特别值得记录下来。这篇文章我就围绕这块板子把Qt交叉编译环境怎么搭、GPU渲染怎么调、中间有哪些坑完整摊开来讲。不管你是刚拿到RK3588开发板准备做HMI人机界面还是要在工业设备上搞一套带3D特效的Qt应用又或者只是想把交叉编译这套流程搞明白这篇文章都适合你。我会把每一步的命令、参数、报错和解决办法都写出来尽量让大家少走弯路。1. 项目整体设计与方案选型解析1.1 为什么是RK3588为什么是Qt先说硬件。RK3588这芯片大家应该不陌生8nm制程4颗A76大核加4颗A55小核主频最高能到2.4GHzGPU是Mali-G610 MP4支持OpenGL ES 3.2和Vulkan。这配置放在工业控制、智慧屏、边缘计算盒子里属于非常能打的方案。创龙这块板子我拿到手的第一感觉是工规料挺足宽温、静电防护、接口齐全跟市面上那些消费级开发板不是一个路子。对做产品的人来说这种板子最大的价值在于可靠性也就是说你在这个平台上调通的软件后面出问题概率低很多。图形界面这块为什么选Qt而不选别的原因很直接。第一Qt在Linux上的生态足够成熟QWidget做传统工业界面、QML做炫酷的动态效果都能覆盖第二RK3588的Mali GPU对OpenGL ES的支持很好而Qt的渲染引擎正是基于OpenGL ES的两者是天然搭配第三Qt的跨平台特性让代码能在x86和ARM之间无缝切换这对开发调试阶段太重要了。1.2 交叉编译方案的整体思路这里我得先解释一个概念。RK3588是ARM架构你平时开发用的电脑大概率是x86架构在x86上编译出来的程序ARM板子直接跑不了。所谓交叉编译就是在x86的开发机上用一套针对ARM架构的交叉编译器把程序编译成ARM能识别的机器码再部署到板子上运行。那为什么不直接在板子上编译呢可以但效率很低。ARM板子的CPU再怎么强跟动辄几十核的桌面CPU比起来还是有差距。一个Qt库全量编译在板子上可能要跑几个小时在开发机上十几分钟就搞定了。而且开发机上的编译工具链更完善排查依赖关系也更方便。我这次的方案路线是这样的开发机上装Ubuntu 22.04然后安装aarch64交叉编译工具链再用Qt官方源码交叉编译出一套ARM版的Qt库最后在开发机上用这套库编译应用程序部署到板子上运行。这套路是嵌入式Linux图形开发的经典玩法很多人甚至公司项目都这么干。1.3 方案的几个关键决策点方案里有一个比较关键的决策就是Qt库的来源。市面上有几个选择用Linaro的二进制包、用Buildroot/Yocto集成的Qt、用创龙BSP自带的Qt库、以及自己用源码编译。我这次选了自己用源码编译原因有三点第一官方源码包最干净编译选项完全可控。我需要哪些模块就编哪些不需要的可以裁剪掉这对最后部署的体积有直接好处。第二BSP自带的Qt库有时候版本偏老或者是针对特定显示方案打过补丁的不便于和开发机上的Qt版本保持一致。而用源码交叉编译开发机装什么版本板子上就编什么版本版本一致性有保障。第三自己编过一遍Qt后面遇到奇怪问题的时候排查思路会清晰很多。很多人遇到Qt运行报错只会百度unknown module但如果自己编译过一看配置选项就知道哪个模块没编进去排错成本低一大截。这里顺带说一嘴很多人关心的版本匹配问题。Qt 5.15系列是LTS版本5.15.2是社区常用的稳定版网上资料也最多遇到问题好搜。Qt 6现在虽然也流行但很多工业行业代码还停留在Qt 5而且5.15.2对OpenGL ES 3.2的支持足够成熟所以我最后选了5.15.2。2. 交叉编译环境搭建全流程2.1 开发机环境准备第一步永远是准备开发机环境。我用的是Ubuntu 22.04 LTS如果你用的是Ubuntu 20.04操作也差不多。Windows用户建议直接装虚拟机跑Ubuntu注意这里一定要选ARM架构的虚拟机系统热词里有人问过为什么VMware要选ARM架构这里解释一下因为最终目标平台是ARM如果用QEMU等工具仿真ARM环境就需要ARM版的Ubuntu镜像做交叉编译本身倒不强制。先更新系统然后安装基础依赖sudo apt update sudo apt upgrade -y sudo apt install build-essential git g gcc make cmake ninja-build \ libxcb-xinerama0-dev libxcb-xinerama0 libxkbcommon-dev \ libgl1-mesa-dev libfontconfig1-dev libdbus-1-dev \ libssl-dev libudev-dev libxcb-icccm4-dev libxcb-keysyms1-dev \ libxcb-image0-dev libxcb-randr0-dev libxcb-render-util0-dev \ libxcb-shape0-dev libxcb-xfixes0-dev libxcb-xkb-dev \ libxkbcommon-x11-dev libx11-xcb-dev libxext-dev libxi-dev \ libxrender-dev libxtst-dev libfreetype6-dev这一坨依赖看着吓人其实大部分是Qt编译时需要的X11相关库。就算你最终在板子上用EGLFS后面会讲跑无头显示编译期间还是需要这些X11的headers不然Qt的xcb插件编不出来。然后是交叉编译工具链。创龙BSP里通常会带一套工具链但我更习惯用Ubuntu官方源里的交叉编译套件sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu装完以后验证一下aarch64-linux-gnu-gcc --version如果能看到版本号说明工具链就位了。这一套工具链叫做GNU交叉编译工具链热词里有人问为什么还要用gcc-arm工具链交叉编译其实就是说板子上虽然装了Ubuntu系统rk3588 ubuntu板子系统自己也能编译但性能不够所以开发机上用aarch64-linux-gnu-gcc来提前编好这个套路在嵌入式领域是标配。2.2 获取Qt源码并准备编译配置接下来是重头戏Qt源码。我用的版本是qt-everywhere-src-5.15.2大家可以到Qt官网下载或者用清华镜像站避免注册账号的麻烦。wget https://download.qt.io/archive/qt/5.15/5.15.2/single/qt-everywhere-src-5.15.2.tar.xz tar -xf qt-everywhere-src-5.15.2.tar.xz cd qt-everywhere-src-5.15.2解压之后需要创建一个针对ARM架构的qmake配置。Qt的构建系统是基于qmake的通过修改qtbase/mkspecs/linux-aarch64-gnu-g这个目录下的qmake.conf来告诉Qt交叉编译器在哪里。实际操作中我倾向于在源码目录外建一个build目录这样不会污染源码树mkdir build-qt-arm cd build-qt-arm然后执行configure。这里我把关键的配置参数展开说一下../qt-everywhere-src-5.15.2/configure \ -prefix /usr/local/qt5-arm \ -opensource -confirm-license \ -xplatform linux-aarch64-gnu-g \ -nomake examples -nomake tests \ -no-opengl -no-eglfs -skip qtwayland \ -qt-xcb -no-xkbcommon-qt \ -feature-glib等一下看到-no-opengl你可能会奇怪标题不是GPU渲染吗怎么把OpenGL给关掉了这里有个坑我必须提醒大家Qt 5.15源码在交叉编译的时候如果直接开OpenGL会在检测EGL/GLES库时报一堆错因为没有ARM版的Mali驱动库在环境里。处理方式有两种第一种先不编OpenGL也就是上面的参数后面单独处理GPU库。第二种给 configure 传-opengl es2并且把板子上的libMali头文件和链接库提供给编译环境。这个方法配置复杂一些很多人在这一步卡住。我这次采用了一个更稳妥的做法第一次configure先不启用OpenGL把Qt基础体系编出来跑通然后单独去解决GPU渲染库的问题这样每一步都能验证不会一上来就陷入编译错误泥潭。2.3 编译与安装configure执行完毕没有报错的话就可以开始编译了。这里建议用多线程编译来提速make -j$(nproc)nproc是CPU核心数如果你的开发机有16核就写make -j16。第一次全量编译Qt 5.15大概需要20到40分钟取决于机器性能。编译完成后执行安装sudo make install这样Qt库就被安装到了/usr/local/qt5-arm目录下。这里有两点值得留意第一这个目录是放在开发机的/usr/local/qt5-arm下的它最终要拷贝到开发板的对应位置。你可以直接从开发机上把整个目录打包拷过去也可以用NFS挂载的方式让板子直接访问后面实操篇我会展开讲。第二前面那套configure参数里-nomake examples -nomake tests是裁剪选项build会快很多。另外如果你只是做一个简单HMI其实还可以加-skip qt3d -skip qtcanvas3d -skip qtpurchasing之类进一步缩短编译时间。不过我在项目里用了部分图表功能所以保留了qtcharts模块它是被默认构建的不需要额外指定。2.4 部署到开发板与路径规划Qt库在开发机上安装好后需要同步到开发板。这里有个路径规划的问题配置时用了-prefix /usr/local/qt5-arm这表示Qt库在运行时的默认前缀就是/usr/local/qt5-arm。所以你得保证开发板上也把这个目录放在同样的路径下。部署方式我推荐两种方式一SD卡拷贝。用tar打包然后通过U盘或者scp传到板子上解压tar -czf qt5-arm.tar.gz /usr/local/qt5-arm scp qt5-arm.tar.gz root板子的IP:/root/方式二NFS挂载。如果调试阶段频繁改代码这条方式效率最高。在开发机上把/usr/local/qt5-arm通过NFS共享出来板子上挂载过去省去了反复拷贝sudo apt install nfs-kernel-server # 修改 /etc/exports添加以下行 /usr/local/qt5-arm *(rw,sync,no_subtree_check,no_root_squash)然后板子上执行mount -t nfs 开发机IP:/usr/local/qt5-arm /usr/local/qt5-arm挂载后还需要设置几个环境变量。这里我先剧透一下把.bashrc里要加的几行写出来export QT_ROOT/usr/local/qt5-arm export PATH$QT_ROOT/bin:$PATH export LD_LIBRARY_PATH$QT_ROOT/lib:$LD_LIBRARY_PATH export QT_QPA_PLATFORMeglfs export QT_QPA_EGLFS_INTEGRATIONeglfs_kms至于QT_QPA_PLATFORM为什么要设置成eglfs以及eglfs_kms是什么第三部分会详细讲。这里只要先把环境变量搞对Qt库就能跑了。3. GPU图形渲染原理与关键配置3.1 RK3588的Mali GPU与Qt渲染路径RK3588的GPU是Arm Mali-G610 MP4峰值算力大概在1.3 TFLOPS左右对于2D/3D图形的UI渲染绰绰有余。Mali-G610支持OpenGL ES 3.2、Vulkan 1.2、OpenCL 2.2而且支持AFBC帧缓冲压缩技术能在一定程度上提高渲染带宽利用率。Qt的渲染方式是分层级的。对于QWidget和QMLQt默认会通过软件光栅器Raster绘制然后通过OpenGL ES把纹理上屏对Qt Quick场景图Scene Graph它可以直接用OpenGL ES进行GPU加速渲染。换句话说Qt应用要跑出GPU图形渲染效果核心前提是板子上必须有可用的OpenGL ES运行环境。而RK3588上Linux的OpenGL ES支持不靠Mesa软件渲染靠的是Rockchip提供的Mali GPU用户态驱动库也就是大家常说的libmaliRK3588上是librk_mali或者版本命名的libmali-g610。3.2 配置libmali与EGL库这一步是整个GPU渲染方案的核心。创龙BSP的系统镜像里一般已经带好了libmali不过在某些最小系统或自己移植的Ubuntu镜像里热词里有人问rk3588移植Ubuntu说明这确实是大家常干的可能没有默认带上。先检查板子上有没有Mali库find /usr/lib -name *mali* ldconfig -p | grep mali如果输出里能看到libmali.so等相关文件说明驱动在系统里。如果没有就得从Rockchip的BSP中提取或者下载对应的Mali用户态驱动安装包。拿到libmali后还要确认头文件。编译OpenGL ES应用需要EGL、GLES2、GLES3的头文件这些头文件一般在BSP的usr/include里。如果系统里没有就手动拿到头文件放到/usr/include/EGL、/usr/include/GLES2、/usr/include/GLES3目录下。这块有个细节要注意libmali的so文件可能不是标准的Linux命名方式比如叫libmali-g610.so你需要创建一个libGLESv2.so、libEGL.so的软链接到它应用才能找到ln -sf /usr/lib/libmali-g610.so /usr/lib/libEGL.so ln -sf /usr/lib/libmali-g610.so /usr/lib/libGLESv2.so ln -sf /usr/lib/libmali-g610.so /usr/lib/libGLESv1_CM.so这样任何需要EGL、GLES2的应用都能通过标准动态库名找到Mali驱动了。3.3 Qt的EGLFS平台插件与KMS显示栈前面环境变量里我提到了QT_QPA_PLATFORMeglfs。这其实是Qt在嵌入式Linux上实现GPU渲染的关键。Qt支持的显示平台插件分为几类linuxfb、xcb、eglfs和wayland。在开发板上如果没有跑X Server或者Wayland compositor最直接的显示方案就是eglfs。EGLFS不是一个X11客户程序它让Qt应用直接通过EGL变成独立显示程序不走X Server直接和KMSKernel Mode Setting打交道。RK3588上有多个显示输出HDMI、DP、eDP、MIPI DSI等KMS负责管理这些显示控制器。EGLFS的eglfs_kms集成插件就是Qt用来对接KMS的桥。要让Qt的EGLFS正常工作前提是你把Qt编出了eglfs和eglfs_kms插件。这就是为什么我建议在开发机上先跑通基础版Qt后要二次编译或者编译时补上EGL插件的原因。如果你用的是BSP里的Qt库一般这些插件都是现成的。但如果是自己完整交叉编译那么需要在configure时明确加上-configure 参数中-opengl es2 -eglfs而且在编译前要把Mali驱动库的路径和头文件路径配置到编译环境中让Qt configure能找到。你可以设置环境变量export LIBEGL_INCLUDE_DIR/usr/include export LIBEGL_LIB_DIR/usr/lib export LIBGLESV2_INCLUDE_DIR/usr/include export LIBGLESV2_LIB_DIR/usr/lib然后进入build目录重新以-opengl es2 -eglfs参数configure编译替换。3.4 如何验证GPU渲染是否真正生效环境搭好了怎么验证GPU图形渲染是真的在GPU上跑的而不是软件渲染的这是很多人忽略的点。最直接的验证方法是用Qt自带的场景图测试工具在板子上跑一个QML应用然后观察第一看启动日志。EGLFS模式下Qt启动日志会打印EGL Vendor信息如果你能看到Mali相关的关键字说明EGL加载的是Mali驱动。第二用glmark2这个工具测试OpenGL ES性能glmark2-es2如果glmark2跑出几百上千的帧率说明Mali驱动工作正常。如果只有几十甚至几个fps大概率是走了软件渲染Mesa llvmpipe。第三用gpu_memory或mali_ko相关的调试文件检查Mali驱动是否在跑cat /sys/kernel/debug/mali/gpu_utilisation如果能有utilization百分比输出说明Mali GPU有实际任务在执行。4. 从零到一Qt应用在RK3588上的运行实录4.1 创建第一个Qt交叉编译项目环境都搭好了我们用实例来走一遍完整编译部署流程。创建一个最简单的QML应用。在开发机上执行mkdir ~/rk3588-qt-demo cd ~/rk3588-qt-demo用Qt Creator新建或手写以下文件。先创建demo.proQT quick CONFIG c11 TARGET demo TEMPLATE app SOURCES src/main.cpp RESOURCES qml.qrc再创建src/main.cpp#include QGuiApplication #include QQmlApplicationEngine int main(int argc, char *argv[]) { QGuiApplication app(argc, argv); QQmlApplicationEngine engine; engine.load(QUrl(QStringLiteral(qrc:/main.qml))); if (engine.rootObjects().isEmpty()) return -1; return app.exec(); }再创建一个qml.qrc资源文件调用main.qmlimport QtQuick 2.12 import QtQuick.Window 2.12 Window { visible: true width: 1920 height: 1080 title: qsTr(RK3588 Qt GPU Demo) Rectangle { anchors.fill: parent color: black Rectangle { width: 300 height: 300 radius: 150 color: red x: parent.width / 2 - width / 2 y: parent.height / 2 - height / 2 NumberAnimation on rotation { from: 0 to: 360 duration: 3000 loops: Animation.Infinite } } } }这个demo很简单但已经用到了Qt Quick的场景图动画能直观看出GPU渲染是否流畅。4.2 使用交叉编译工具链构建应用开发机上的编译流程关键就在于让qmake找到ARM版的Qt工具。由于我们已经把ARM版Qt安装到了/usr/local/qt5-arm所以直接调用这个目录下的qmakecd ~/rk3588-qt-demo /usr/local/qt5-arm/bin/qmake demo.pro makeqmake会根据平台配置生成对应ARM架构的Makefilemake后得到的demo二进制就是ARM版的可执行文件。你可以用file命令验证一下file demo输出应该类似于ELF 64-bit LSB executable, ARM aarch64这才是真正能在RK3588上跑的程序。如果显示的是x86-64说明qmake用错了还在用开发机原生的Qt。4.3 部署并在开发板上运行编译好的demo以及用到的Qt库、Mali驱动都要在板子上就位。我用一个简单的scp把二进制和Qt库传到板子上scp demo root板子的IP:/root/demo/ scp -r /usr/local/qt5-arm/lib root板子的IP:/usr/local/qt5-arm/板子上设置了环境变量后执行cd /root/demo ./demo如果一切正常LCD屏幕上应该会出现一个1920x1080的黑色窗口中间有个红色的圆球在持续旋转而且旋转非常平滑。这个平滑的本质就是Qt Quick的Scene Graph通过OpenGL ES把每一帧都交给Mali GPU渲染没有CPU参与绘制。4.4 性能观察与帧率验证光看着流畅还不够最好能用数据说话。Qt 5.15提供了一种方式开启渲染统计。设置环境变量export QSG_VISUALIZEoverdraw这个会显示overdraw热力图能直观看到哪些区域在过度绘制。要测FPS的话可以在QML里加一帧统计或者用Linux的perf等工具抓GPU负载。更实用的方法是直接在板子上跑export LD_LIBRARY_PATH/usr/local/qt5-arm/lib QT_QPA_PLATFORMeglfs QT_QPA_EGLFS_INTEGRATIONeglfs_kms ./demo同时另一个终端执行watch -n 1 cat /sys/kernel/debug/mali/gpu_utilisation我在实测中一个带多个旋转动画和图表的QML界面GPU利用率大概在30%到60%之间帧率稳定在60fps开启了Vsync。这说明渲染完全由GPU承载效率符合预期。5. 常见问题与排查技巧实录5.1 编译阶段的高频报错与对策这一节我把这几个月实打实踩过的坑整理出来按编译期和运行期分类先看编译期的。第一个高频问题configure时报GLES2/gl2.h: No such file or directory。原因是系统缺少OpenGL ES头文件。解决办法将Mali驱动的头文件目录加入CPLUS_INCLUDE_PATH或者用apt install gcc-aarch64-linux-gnu libgles2-mesa-dev:arm64-style的方法先把依赖头文件装好。第二个高频问题qtbase编译时error: unknown type name constexpr这类错误。这在某些旧工具链上会出一般是工具链版本过老Qt 5.15要求c11完整支持建议升级GCC到9以上版本Ubuntu 22.04自带的aarch64-linux-gnu交叉编译器通常是11.x没这个问题。第三个高频问题unknown module(s) in qt: serialport 。这个问题热词里出现过不止一次。原因很简单交叉编译Qt时默认没有把SerialPort模块编进make列表或者configure时把它skip了。Qt SerialPort模块是独立的在qt-serialport目录下。如果configure时没有显式加上-make libs某些模块可能编不进去。解决办法是configure时直接指定-skip qtconnectivity -skip qtspeech ...最好不要大量skip模块SerialPort是一个轻量模块默认会编。出现unknown module一般是因为编译install步骤不完整或者使用了另一个版本Qt的qmake。查一下/usr/local/qt5-arm/bin/qmake和当前项目里的qmake是不是同一个。5.2 运行期EGLFS黑屏问题这是另一个高发问题。环境变量设了eglfs程序也启动没有报错但屏幕就是黑屏。这种问题第一反应是查KMS和设备节点权限。在板子上执行ls -l /dev/dri/通常能看到card0和renderD128。如果应用程序是以普通用户运行的可能没有权限访问/dev/dri/card0解决办法有两个把用户加入video组或者直接用root跑demo。usermod -a -G video 用户名如果KMS设备节点路径对但还是黑屏就得看看是不是HDMI没有连接而板子默认输出到了另一路显示接口。RK3588上有HDMI、DP、MIPI DSI等多个显示接口KMS会选择其中一个作为主输出。可以通过cat /sys/class/drm/card0/status查看每个接口的连接状态。如果HDMI没接而系统默认选择了HDMI作为主显示器那就黑屏了。解决方案是在KMS里配置强制输出或者把屏幕接到正确的接口。5.3 GPU加载失败问题如果日志里出现Failed to create EGL display或者EGL_NOT_INITIALIZED说明libmali驱动没有正确加载。最常见的坑就是库文件的软链接没建好系统找不到libEGL.so。另一个坑是libmali的版本与内核不匹配有些开发板刷了较新的内核BSP里的旧libmali可能起不来。排查步骤我一般这样走ldconfig -p | grep -E EGL|GLES确认libEGL.so存在且指向libmali。再用这个简单程序验证EGL能否初始化#include EGL/egl.h #include stdio.h int main() { EGLDisplay dpy eglGetDisplay(EGL_DEFAULT_DISPLAY); if (dpy EGL_NO_DISPLAY) { printf(No display\n); return 1; } EGLint major, minor; if (!eglInitialize(dpy, major, minor)) { printf(EGL init failed\n); return 1; } printf(EGL %d.%d\n, major, minor); return 0; }交叉编译后放到板子上跑如果EGL显示版本号正常说明GPU基础环境OK如果卡在这一步基本就是libmali本身的问题去BSP里换一个匹配版本的库就好。5.4 性能达不到60帧的排查方向有朋友会遇到这种情况demo跑起来了也确实是GPU渲染但帧率上不去动画卡顿。常见的性能瓶颈有这么几个第一个是CPU端场景图构建瓶颈。Qt Quick场景图每一帧需要遍历QML树如果界面里Widget和Binding过多CPU会成瓶颈。解决办法是在QML里减少重复计算的属性绑定用Loader延迟加载减少复杂Shader效果使用。第二个是纹理上传瓶颈。如果你的应用在界面上放了很大的图片每次切换页面都会把纹理从CPU内存拷贝到GPU显存时间长了会卡。RK3588的内存带宽足够大但依然建议用Image组件的sourceSize属性把图片缩小到实际显示尺寸再加载。第三个是vsync对齐问题。如果应用没有和显示器的vsync做同步撕裂和卡顿感会很明显。Qt的QSG_RENDER_LOOP有basic、windows两种模式在EGLFS下一般默认用basic它会阻塞渲染线程配合vsync等待。实测中保持vsync对齐比盲目提升GPU频率更关键。另外一个小提醒不要在QML里频繁创建和销毁对象这样会导致频繁的GL资源分配释放。尽量用对象池或者visible: false来隐藏而不是销毁。5.5 一个容易被忽略的问题文件系统空间不足RK3588开发板的eMMC一般是16GB到64GB但有些工业板预留空间给用户数据根文件系统可能只剩几个GB。Qt库全量装下来可能要占1GB多再算上应用和后续日志空间很快会吃紧。解决办法有几个方向一个是在configure时剥掉不需要的模块我再贴一次我这次项目用到的裁剪配置-skip qtwebengine -skip qtwebview -skip qtwebchannel \ -skip qtlocation -skip qtsensors -skip qtpurchasing \ -skip qtdatavis3d -skip qtgraphs -skip qtvirtualkeyboard另一个是给板子外挂U盘或者TF卡并把/usr/local/qt5-arm放到外置存储里。启动时先挂载再启动应用也是工业现场的常见做法。6. 后续可以继续深入的方向这套环境打通之后等于打开了RK3588 Qt开发的大门。接下来的扩展方向其实很多我这里说几个比较实用的。如果你要做视觉类产品可以在Python端集成YOLOv8做检测通过共享内存或UDP把检测到的目标坐标交给Qt界面绘制框选这也是目前不少智能工业相机的架构思路。如果要做视觉SLAMRK3588的算力足够跑ORB-SLAM3这类算法界面显示轨迹和实时位姿用Qt的OpenGL模块很合适。再比如你做完USB摄像头采集之后可以用Qt做的RTSP流管理界面把处理后的视频流推给局域网内的其他设备。还有板子自带的编解码能力RK3588内置VPU支持H.264/H.265硬编解码Qt里用QVideoSink或FFmpeg把视频帧喂给GPU做特效叠加整个链路的性能会非常可观。说实话RK3588这套平台能玩的东西太多了我现在每次拿到新板卡还是会先搭一遍这套Qt交叉编译环境因为不管是后面做算法还是做交互图形显示一定是最终给用户看的东西。这次把完整的记录和排坑经验写出来希望能帮到正准备在这一类国产工业开发板上做图形开发的朋友。