开源图形驱动在 OpenHarmony 上的使用和落地

本文转载自 OpenHarmony TSC 官方微信公众号《峰会回顾第10期 | 开源图形驱动在OpenHarmony上的使用和落地》

演讲嘉宾 | 黄   然

回顾整理 | 廖   涛

排版校对 | 李萍萍

嘉宾简介

黄然，华为终端 BG 软件部资深图形技术专家，华为终端游戏标准、工具和分析创始人，GPU Turbo 黑科技核心成员，在 OpenHarmony 社区上担任开源图形驱动 SIG、游戏 SIG、兼容性工作组组长等职务。

内容来源

第一届开放原子开源基金会 OpenHarmony 技术峰会——OS 内核及视窗分论坛

视频回顾

正 文 内 容

图形驱动也是一种软件程序，它串联了操作系统和应用程序与计算机图形硬件进行通信和交互，是发挥硬件性能为操作系统提供高质量图形显示的关键环节。OpenHarmony 在开源图形驱动的使用和落地上做了哪些工作呢？OpenHarmony 游戏 SIG 组、图形驱动 SIG 组组长、华为终端图形资深技术专家黄然在第一届 OpenHarmony 技术峰会上给大家带来了几点分享。

01►OpenHarmony 图形驱动面临的挑战

图形驱动技术的演进始终跟 GPU 硬件的发展相关。1975 年至今，随着 GPU 硬件由早期的专业领域高端图形工作站发展到台式机 GPU 显卡，再到如今的移动终端、云和服务器 GPU 显卡，图形驱动 API 也由 OpenGL 演进到了 DirectX。

目前，图形驱动领域的主流厂商都对自身的核心代码闭源，Arm Mali、Qualcomm Adreno 和 Nvidia 等开源图形驱动也并没有特别“Open”。

随着开源运动的兴起和成功，AMD 和英特尔等公司的图形驱动开源建立了良好的生态，也取得了不错的效果。对 OpenHarmony 这样一个完全开源的操作系统来说，图形开源驱动有很好的借鉴和学习意义，当然也存在着诸多挑战。掌握开源图形驱动有多难呢？首先图形驱动的开发和研究需要具备扎实的软硬件开发功底，且由于开源图形驱动在国内的发展很慢，少有开发者专门从事该项工作，缺乏技术交流和实践经验分享。下图为黄然老师前期在开源驱动领域学习和研究所做的笔记：

此外，对于 OpenHarmony 来说，当前大部分的小厂商无法获得闭源 GPU 厂商的支持，导致视觉流畅体验较差，限制了非常多 OpenHarmony 产品的商用，在一定程度上也阻碍了 OpenHarmony 生态的推广。

02►开源图形驱动架构介绍

由于从驱动角度，OpenHarmony 富设备的内核是基于 Linux 的，故首先介绍下 Linux 开源驱动的整体架构。整个驱动的架构可以分为 2D 和 3D 两个部分，2D 部分的比较老的框架是基于 X11，而比较新的框架是基于 Wayland。

3D 的部分驱动通过 mesa，将 OpenGLES 或者 Vulkan 的 API 以及 shader 转化为硬件的 ISA。而 2D 的 DDX 驱动通过 glamor 也可以走到 mesa 层，这样避免了 2D 和 3D 分岔的驱动路线（过去曾经是分岔的，2D 走 DDX）。

整体的驱动是 UMS+KMS 结构，UMS 负责用户层驱动的解析，而 KMS 用来做显示和硬件渲染，通过 libdrm 和 DRM 来形成 UMS 到 KMS 的传递。

在图形驱动中有几个关键概念：

一是 LLVM、TGSI 和 Gallium。TGSI 是一种用于描述着色器的中间语言，是所有驱动程序使用的唯一中间表示，所有的 Shader 都会转化为中间的 IR。而 Gallium 是 LLVM 的后端，能够基于不同硬件进行不同硬件的 ISA 绘制，如图中的 radeonsi 就是 AMD 的 radeon 的后端渲染。

二是 ISA。ISA 由控制流（CF）指令、ALU 指令、通过纹理缓存提取的指令和通过顶点缓存提取的指令组成，其中控制流程序通过使用控制流指令（条件跳转、循环和子例程）来指导程序子句的流，包括内存分配指令和其他指令，这些指令可以指定顶点和几何程序何时完成相关操作，类似 CPU 的汇编语言。

三是 Fence。Fence 能够让 GPU 和 CPU 协调工作，提高图像显示的速度。通过 Fence 机制产生的 GPU 的事件，能够保证用户态程序下发的渲染命令被顺序执行，从而保证上层应用程序渲染相关数据的一致性。

03►开源图形驱动在 OpenHarmony 上的移植

OpenHarmony 驱动框架支持多种接入模式，能够实现南向硬件的快速部署。其中，显示框架支持 Display_Gralloc、Display_Gfx 和 Device HDI 的 3 类南向接口，其中，Display_Gralloc 负责内存分配；Display_Gfx 负责图形硬件 2D 绘制，可以用于离线合成；Device HDI 负责显示设备特性管理，包括屏幕显示，在线及离线硬件合成，硬件 Vsync，显示设备色彩管理等。在开发板能力支持方面，RK3568 和 HI3516dv300 支持 DRM 内存分配、DRM 送显以及硬件离线合成，HI3751V350 支持支持 FbDev 和 DmaBuf-Heap、支持 FbDev 显示，不支持硬件离线合成。

针对上述 OpenHarmony 驱动框架的整体情况，开源 GPU 驱动的适配工作主要分为以下 3 个阶段进行：（1）验证内核 panfrost 驱动和用户态 panfrost 驱动可以正常工作；（2）开源 GPU 驱动适配 OpenHarmony（Flutter+weston）旧框架；（3）开源 GPU 驱动适配 OpenHarmony（RenderService）新框架。目前，越来越多的兴趣开发者参与到了 OpenHarmony 的开源图形驱动适配和移植的工作中，近期有一些用户已经成功将高通开源驱动移植到移动终端上，使其能够运行一些 2D 和 3D 的应用。这意味着开源驱动在 OpenHarmony 上生态正在朝着良好的方向发展。

从 GLmark2 跑分情况来看，OpenHarmony 开源驱动在 2D 的纹理处理等方面表现比闭源驱动优异，在关键的着色和阴影、地形等偏 3D 的方面表现还较差。即便如此，在 2D 和 3D 开源图形驱动上的性能提升已经足以满足绝大多数产品的需求。

当然，在这个过程中，还有一些伙伴参考当前的工作，把高通的 freedreno 开源驱动也完成了移植，并且可以在小米等手机上可以运行和使用开源驱动，如下：

未来我们还会在 X86 基础的 AMD 以及 Intel GPU 上使能开源驱动，服务于 OpenHamrony，也希望更多的小伙伴可以一起加入社区微信群 SIG-OpenGfxDrv 共建图形驱动，对应的 gitee 链接为：https://gitee.com/openharmony/third_party_mesa3d

04►总结 &展望

真正想做好图形竞争力，就要了解 GPU 的工作机制和图形驱动原理，OpenHarmony 社区正是一个交流和学习的良好平台；OpenHarmony 开源图形驱动是未来趋势，也会是历史最终选择，希望有越来越多的兴趣开发者能够参与到开源图形驱动的适配和移植工作中来，共建 OpenHarmony 生态。

点击关注了解更多OpenHarmony TSC技术干货内容