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系統鏡像燒錄與調試實踐
