https://docs.openharmony.cn/pages/v5.0/zh-cn/device-dev/quick-start/quickstart-appendix-compiledform.md
官方给的标准系统就是RK3568, 所以肯定可以,
关于硬件加速部分
看了鸿蒙RK3568开发板的GPU编译配置,只能说能用
https://docs.openharmony.cn/pages/v4.1/zh-cn/device-dev/porting/porting-dayu200-on_standard-demo.md#gpu
图形库是musl
musl与RK mali库的差异
1.库的区别
| 维度 | OpenHarmony musl 库 | 原厂 RK Mali 库 |
|---|---|---|
| 核心作用 | 提供轻量级 C 运行时库支持（如内存管理、系统调用），可能与 GPU 底层驱动或图形框架的编译相关。 | 提供完整的 GPU 硬件驱动和图形 API（如 OpenGL ES、Vulkan）实现，直接控制 Mali GPU 硬件。 |
| 依赖关系 | 属于系统基础库，GPU 功能需在此基础上调用硬件驱动或图形接口。 | 直接与 GPU 硬件交互，是图形渲染、计算加速的核心。 |
| 适用场景 | 轻量系统（如 RK3568 的 32 位模式）的基础编译和系统适配。 | 需要高性能图形渲染、游戏、UI 加速等场景。 |
2. 性能与优化
| 维度 | OpenHarmony musl 库 | 原厂 RK Mali 库 |
|---|---|---|
| 浮点运算 | 使用 -mfloat-abi=softfp，兼容无 FPU 的低端设备，但浮点性能较差。 | 默认启用硬浮点（hardfp），直接利用 Mali GPU 的浮点单元，性能更高。 |
| 指令集优化 | -march=armv7-a和 -mtune=generic-armv7-a仅针对通用 ARMv7 架构优化。 | 针对 Mali GPU 的微架构（如 Mali-G52）深度优化，指令级并行性更强。 |
| 图形加速能力 | 无直接图形加速功能，可能仅支持基础的显示输出（如 Framebuffer）。 | 支持 OpenGL ES 3.2、Vulkan 1.2 等高级图形 API，提供硬件级渲染加速。 |
3. 兼容性与适配
| 维度 | OpenHarmony musl 库 | 原厂 RK Mali 库 |
|---|---|---|
| 系统兼容性 | 为 OpenHarmony 轻量/小型系统定制，与 musl 库和 LLVM 工具链深度绑定。 | 需依赖 Linux 内核驱动（如 DRM/KMS）和用户态库，适配复杂系统（如 Android、Linux）。 |
| 硬件依赖性 | 适配 RK3568 的 32/64 位模式，但未针对 Mali GPU 特性专门优化。 | 紧密依赖 Mali GPU 硬件，需原厂内核驱动和固件支持。 |
| 跨平台移植 | 基于 OpenHarmony 的编译框架，可快速移植到其他符合架构的芯片。 | 需原厂提供 BSP 支持，移植成本高（如不同芯片的 Mali GPU 版本差异）。 |
4.结论
能用, 效果应该相当于电脑的集显吧。
- 是否需要原厂 Mali 库？
- 如果项目需要 3D 渲染、游戏、复杂 UI 动画 等 GPU 加速功能，必须依赖原厂 Mali 库。
- 如果仅需 基础显示输出（如工业 HMI），且设备资源受限（如内存 < 512MB），可基于 OpenHarmony musl 库简化系统。
- 性能取舍
softfp模式可能导致图形渲染性能下降 20%~30%，若硬件支持 FPU，建议强制切为hardfp（需修改编译参数）。
- 混合使用场景
- 可尝试 musl 库 + 原厂 Mali 驱动 的组合：musl 提供轻量系统支持，Mali 库提供图形加速（需验证兼容性）。能不能实现呃, 只能说试试。
系列文章目录
OpenHarmony移植RK3568系列技术文档
[第一篇] RK3568平台OpenHarmony系统移植可行性评估
[第二篇] OpenHarmony 5.1.0 Release源码获取与仓库管理
[第三篇] OpenHarmony 5.1.0 Release源码架构深度解析
[第四篇] OpenHarmony 5.1.0构建环境配置指南
[第五篇] RK3568平台OpenHarmony 5.1.0编译指南：硬件配置需求与编译时长
[第六篇] RK3568平台OpenHarmony 5.1.0与原生固件分区结构对比分析
[第七篇] RK3568平台OpenHarmony 5.1.0系统镜像烧录与调试实践
