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

演讲嘉宾 | 黄   然

回顾整理 | 廖   涛

排版校对 | 李萍萍

嘉宾简介

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

内容来源

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

视频回顾

视频链接

峰会回顾第10期 | 开源图形驱动在OpenHarmony上的使用和落地（黄然）_哔哩哔哩_bilibili

正 文 内 容

图形驱动也是一种软件程序，它串联了操作系统和应用程序与计算机图形硬件进行通信和交互，是发挥硬件性能为操作系统提供高质量图形显示的关键环节。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技术干货内容