1. 前言图形子系统是linux系统中比较复杂的子系统之一:对下,它要管理形态各异的、性能各异的显示相关的器件;对上,它要向应用程序提供易用的、友好的、功能强大的图形用户界面(GUI)。因此,它是linux系统中少有的、和用户空间程序(甚至是用户)息息相关的一个子系统。 本文是图形子系统分析文章的第一篇,也是提纲挈领的一篇,将会从整体上,对linux显示子系统做一个简单的概述,进而罗列出显示子系统的软件构成,后续的文章将会围绕这些软件一一展开分析。 注1:本文所有的描述将以原生linux系统为例(如Ubuntu、Debian等),对其它基于linux的系统(如Android),部分内容会不适用。 注2:本文很多图片都是从网上搜集而来的(很多是从维基百科)。虽然蜗窝的宗旨是用自己的语言表述,尽量自己画图,但是linux图形子系统太复杂了,蜗蜗的理解有限,而老外的图画的实在太好了哈哈哈。 2. 概念介绍2.1 GUI(Graphical User Interface,图形用户界面)linux图形子系统的本质,是提供图形化的人机交互(human-computer interaction)界面,也即常说的GUI(Graphical User Interface)。而人机交互的本质,是人脑通过人的输出设备(动作、声音等),控制电脑的输入设备,电脑经过一系列的处理后,经由电脑的输出设备将结果输出,人脑再通过人的输入设备接收电脑的输出,最终实现“人脑<-->电脑”之间的人机交互。下面一幅摘自维基百科的图片(可从“这里”查看比较清晰的SVG格式的原始图片),对上述过程做了很好的总结: 该图以一个非常前卫的应用场景----虚拟现实(VR,Virtual Reality)游戏,说明了以图形化为主的人机交互过程: 1)人脑通过动作、声音(对人脑而言,是output),控制电脑的输入设备,包括键盘、鼠标、操作杆、麦克风、游戏手柄(包含加速度计、陀螺仪等传感器)。 注3:图中提到了VR场景的典型帧率(1280×800@95fps for VR),这是一个非常庞大的信息输出,要求图形子系统能10.5ms的时间内,生成并输出一帧,以RGBA的数据格式为例,每秒需要处理的数据量是1280x800x95x4x8=3.11296Gb,压力和挑战是相当大的(更不用提1080P了)。 2.2 Windowing system(窗口系统)窗口系统,是GUI的一种(也是当前计算机设备、智能设备广泛使用的一种),以WIMP (windows、icons、menus、pointer) 的形式,提供人机交互接口。Linux系统中有很多窗口系统的实现,如X Window System、Wayland、Android SurfaceFlinger等,虽然形态各异,但思路大致相同,包含如下要点: 1)一般都使用client-server架构,server(称作display server,或者windows server、compositor等等)管理所有输入设备,以及用于输出的显示设备。 有关Windowing system的详细解释,请参考:https://en./wiki/Windowing_system。 2.3 X Window System似乎终于要进入正题了。 X Window System是Windowing System一种实现,广泛使用于UNIX-like的操作系统上(当然也包括Linux系统),由MIT(Massachusetts Institute of Technology,麻省理工学院)在1984年发布。下图(可从“这里”查看比较清晰的SVG格式的原始图片)是它的典型架构: 1)X Window System简称X,或者X11,或者X-Windows。之所以称作X,是因为在字母表中X位于W之后,而W是MIT在X之前所使用的GUI系统。之所以称作X11,是因为在1987年的时候,X Window System已经进化到第11个版本了,后续所有的X,都是基于X11版本发展而来的(变动不是很大)。为了方便,后续我们都以X代指X Window System。 2.4 窗口管理器、GUI工具集、桌面环境及其它前面讲过,X作为Windowing system中的一种,只提供了实现GUI环境的基本框架,其它的UI设计所需的button、menu、window title-bar styles等基本元素,则是由第三方的应用程序提供。这些应用程序主要包括:窗口管理器(window manager)、GUI工具集(GUI widget toolkit)和桌面环境(desktop environment)。 窗口管理器负责控制应用程序窗口(application windows)的布局和外观,使每个应用程序窗口尽量以统一、一致的方式呈现给用户,如针对X的最简单的窗口管理程序--twm(Tab Window Manager)。 GUI工具集是Windowing system之上的进一步的封装。还是以X为例,它通过xlib提供给应用程序的API,仅仅可以绘制基本的图形单元(点、线、面等等),这些基本的图形单元,要组合成复杂的应用程序,还有很多很多细碎、繁杂的任务要做。因此,一些特定的操作系统,会在X的基础上,封装出一些更为便利的GUI接口,方便应用程序使用,如Microwindows、GTK+、QT等等。 桌面环境是应用程序级别的封装,通过提供一系列界面一致、操作方式一致的应用程序,使系统以更为友好的方式向用户提供服务。Linux系统比较主流的桌面环境包括GNOME、KDE等等。 2.5 3D渲染、硬件加速、OpenGL及其它渲染(Render)在电脑绘图中,是指:用软件从模型生成图像的过程。模型是用严格定义的语言或者数据结构对于三维物体的描述,它包括几何、视点、纹理以及照明信息。图像是数字图像或者位图图像。 上面的定义摘录自“百度百科”,它是着重提及“三维物体”,也就是我们常说的3D渲染。其实我们在GUI编程中习以为常的点、线、矩形等等的绘制,也是渲染的过程中,只不过是2D渲染。2D渲染面临的计算复杂度和性能问题没有3D厉害,因此渲染一般都是指3D渲染。 在计算机中,2D渲染一般是由CPU完成(也可以由专门的硬件模块完成)。3D渲染也可以由CPU完成,但面临性能问题,因此大多数平台都会使用单独硬件模块(GPU或者显卡)负责3D渲染。这种通过特定功能的硬件模块,来处理那些CPU不擅长的事务的方法,称作硬件加速(Hardware acceleration),相应的硬件模块,就是硬件加速模块。 众所周知,硬件设备是多种多样的,为了方便应用程序的开发,需要一个稳定的、最好是跨平台的API,定义渲染有关的行为和动作。OpenGL(Open Graphics Library)就是这类API的一种,也是最为广泛接纳的一种。 虽然OpenGL只是一个API,但由于3D绘图的复杂性,它也是相当的复杂的。不过,归根结底,它的目的有两个: 1)对上,屏蔽硬件细节,为应用程序提供相对稳定的、平台无关的3D图像处理API(当然,也可以是2D)。 另外,openGL的一个重要特性,是独立于操作系统和窗口系统而存在的,具体可以参考后面软件框架相关的章节。 3. 软件框架通过第2章的介绍,linux系统中图形有关的软件层次已经呼之欲出,具体如下: 该层次图中大部分的内容,已经在第2章解释过了,这里再补充说明一下: 1)该图片没有体现3D渲染、硬件加速等有关的内容,而这些内容却是当下移动互联、智能化等产品比较关注的地方,也是linux平台相对薄弱的环节。后续会在软件框架有关的内容中再着重说明。 以X window为例,将hardware、kernel和display server展开如下(可从“这里”查看比较清晰的SVG格式的原始图片): 对于软件架构而言,这张来自维基百科的图片并不是特别合适,因为它包含了太多的细节,从而显得有些杂乱。不过瑕不掩瑜,对本文的描述,也足够了。从向到下,图中包括如下的软件的软件模块: 1)3D-game engine、Applications和Toolkits,应用软件,其中3D-game engine是3D application的一个特例。 4. 后续工作本文有点像一个大杂烩,丢进去太多的东西,每个东西又不能细说。觉得说了很多,又觉得什么都没有说。后续蜗蜗将有针对性的,focus在某些点上面,更进一步的分析,思路如下: 1)将会把显示框架限定到某个确定的实现上,初步计划是:Wayland client+Wayland compositor+Mesa+DRM+KMS,因为它们之中,除了Mesa之外,其它的都是linux系统中显示有关的比较前沿的技术。当然,最重要的,是比较适合移动端的技术。 上文介绍了linux图形子系统基本的软件框架,以及GUI、Windowing system、3D渲染等基本概念。 我觉得,DRI在当前(或者说将来)的linux图形子系统中,有着举足轻重的地位,甚至可以说是新的linux图形框架核心思想的体现。本文将基于linux图形框架的发展历程,从Why、What和How三个角度,介绍DRI框架。 5.为什么需要DRI在GUI环境中,一个Application想要将自身的UI界面呈现给用户,需要2个步骤: 1)根据实际情况,将UI绘制出来,以一定的格式,保存在buffer中。该过程就是常说的“Rendering”。 2)将保存在buffer中的UI数据,显示在display device上。该过程一般称作“送显”。 然后问题就来了:这两个步骤中,display server要承担什么样的角色?回答这个问题之前,我们需要知道这样的一个理念: 在操作系统中,Application不应该直接访问硬件,通常的软件框架是(从上到下):Application<---->Service<---->Driver<---->Hardware。这样考虑的原因主要有二:安全性和共享硬件资源(例如显示设备只有一个,却有多个应用想要显示)。 对稍微有经验的软件开发人员(特别是系统工程师和驱动工程师)来说,这种理念就像杀人偿命、欠债还钱一样天经地义。但直到X server+3D出现之后,一切都不好了。因为X server大喊的着:“让我来!”,给出了这样的框架: 先不考虑上面的GLX、Utah GLX等术语,我们只需要理解一点即可: 看着不错哦,完全满足上面的理念。但计算机游戏、图形设备硬件等开发人员不乐意了:请让我们直接访问硬件!因为很多高性能的图形设备,要求相应的应用程序直接访问硬件,才能实现性能最优[1]。 好像每个人都是对的,怎么办?妥协的结果是,为3D Rendering另起炉灶,给出一个直接访问硬件的框架,DRI就应运而生了,如下: 上面好像讲的都是Rendering有关的内容,那送显呢?还是由display server统一处理比较好,因为显示设备是有限的,多个应用程序的多个界面都要争取这有限的资源,server会统一管理、叠加并显示到屏幕上。而这里叠加的过程,通常称作合成(Compositor)。 6.软件架构DRI是因3D而生,但它却不仅仅是为3D而存在,这背后涉及了最近Linux图形系统设计思路的转变,即: 从以前的:X serve是宇宙的中心,其它的接口都要和我对话。 最终,基于DRI的linux图形系统如下 该框架以基于Wayland的Windowing system为例,描述了linux graphic系统在DRI框架下,通过两条路径(DRM和KMS),分别实现Rendering和送显两个显示步骤。从应用的角度,显示流程是: 1)Application(如3D game)根据用户动作,需要重绘界面,此时它会通过OpenGL|ES、EGL等接口,将一系列的绘图请求,提交给GPU。 a)OpenGL|ES、EGL的实现,可以有多种形式,这里以Mesa 3D为例,所有的3D rendering请求,都会经过该软件库,它会根据实际情况,通过硬件或者软件的方式,响应Application的rendering请求。 2)GPU绘制完成后,将rendering的结果返回给Application。 rendering的结果是以image buffer的形式返回给应用程序。 3)Application将这些绘制完成的图像buffer(可能不知一个)送给Wayland compositor,Wayland compositor会控制硬件,将buffer显示到屏幕上。 Wayland compositor会搜集系统Applications送来的所有image buffers,并处理buffer在屏幕上的坐标、叠加方式后,直接通过ioctl,交给kernel KMS(kernel mode setting)模块,该模块会控制显示控制器将图像显示到具体的显示设备上。 7.DRM和KMSDRM是Direct Rendering Module的缩写,是DRI框架在kernel中的实现,负责管理GPU(或显卡,graphics card)及相应的graphics memory,主要功能有二: 1)统一管理、调度多个应用程序向显卡发送的命令请求,可以类比为管理CPU资源的进程管理(process management)模块。 2)统一管理显示有关的memory(memory可以是GPU专用的,也可以是system ram划给GPU的,后一种方法在嵌入式系统比较常用),该功能由GEM(Graphics Execution Manager)模块实现,主要包括: a) 允许用户空间程序创建、管理、销毁video memory对象(称作“"GEM objects”,以handle为句柄)。 KMS是Kernel Mode Setting的缩写,也称作Atomic KMS,它是一个在linux 4.2版本的kernel上,才最终定性的技术。从字面意义上理解,它要实现的功能比较简单,即:显示模式(display mode)的设置,包括屏幕分辨率(resolution)、颜色深的(color depth)、屏幕刷新率(refresh rate)等等。一般来说,是通过控制display controller的来实现上述功能的。 也许大家会有疑问:这些功能和DRI有什么关系?说实话,关系不大,之所以要在DRI框架里面提及KMS,完全是历史原因,导致KMS的代码,放到DRM中实现了。目前的kernel版本(如4.2之后),KMS和DRM基本上没有什么逻辑耦合(除了代码位于相同目录,以及通过相同的设备节点提供ioctl之外),可以当做独立模块看待。 参考文档 |
|