xorg 架构 将来 以及一些基本常识浅析

很多Xorg相关文章,值得一读:

http://blog.chinaunix.net/uid/269931/abstract/1.html

 

xorg的未来
http://imtx.cn/archives/1119.html
http://www.linuxsir.org/bbs/thread345792.html

看到大家对xorg存在很多的误解和迷惑,下面是我个人的理解
下面都是很简单的问答的形式,力求简单的回答一些常识性的问题,说多了倒还难以理解了。

dri
关于dri,这个是xfree86 4.x就出来了,
主要是用来加速本地应用。现在的机器基本上都是自己用了,关于glx,dri怎么实现的,从底下硬件,到上面driver到xorg,到应用程序怎么工作的,需要一大篇专门的文章来讲
不适合放在这里了。无论dri还是dri2都是类似的,至于drm是什么,drm是实现dri这个框架,需要内核的支持,这个部分就是内核那个部分的东西了。主要是资源管理,锁管理
这些了。光dri这里需要很长的文章来讲,dri实际上可以看作一个中间层,所有的人都通过dri来操作资源,xorg一样。当然client可以是xorg也可以是其他的程序
xorg可以和硬件剥离开了。

xaa/kaa/exa/uxa

xaa是传统的加速框架了。很多基本操作的接口都留出来有硬件加速的接口。但是后来有人研究发现,只需要加速很少的函数就可以了。
http://www.usenix.org/event/usenix04/tech/freenix/full_papers/anholt/anholt.pdf
所以就有了kaa,
kaa
kaa本来是kdrive使用的,Kdrive Acceleration Architecture
什么是 kdrive. kdrive是xserver的一种,有人觉得xfree86太庞大了,所以就有了kdrive,开始的时候叫tinyx,
不同的xserver在代码里面是不同的目录树,都存放在hw下面。
ailantian@vax:~/soft/xorg/temp/xorg-server-1.6.0$ tree -L 1 hw
hw
|-- Makefile.am
|-- Makefile.in
|-- dmx
|-- kdrive
|-- vfb
|-- xfree86
|-- xnest
|-- xquartz
`-- xwin

7 directories, 2 files
ailantian@vax:~/soft/xorg/temp/xorg-server-1.6.0$

xfree86就是xorg的版本了,kdrive下面存放的都是kdrive的代码了。编译完之后就会放在kdrive/src/下面了,编译完成叫Xfbdev.

exa
exa是大家认为kaa这个框架很好,所以移植过来放到了xorg里面,改了个名字叫exa,给xorg用的,当然需要xserver和驱动两方面的工作,
对于xorg这边实现的exa,代码在hw/xfree86/exa/下面,驱动里面会注册这些函数,当调用gc的绘图的函数的时候就会判断驱动是否支持
硬件加速,如果支持就会使用硬件的,所谓的xf86-video-xxx这样的驱动,基本都是exa的实现了,部分还会提供xaa的实现。

uxa
uxa是intel在exa的基础上改了一些东西过来的,现在被抛弃的应该说。在intel这个版本的驱动里面有uxa的实现,和exa基本相同
ailantian@vax:/mnt/sdb1/ubd/soft/xorg/temp/xf86-video-intel-2.6.99.902$ ls
acinclude.m4  autogen.sh  configure.ac  COPYING  cscope.files  cscope.out  Makefile.am  man  README  src  uxa
ailantian@vax:/mnt/sdb1/ubd/soft/xorg/temp/xf86-video-intel-2.6.99.902$


关于xvideo
现在xvideo不是和berly,compiz等等在一起的时候就会闪吗,
http://imtx.cn/archives/1119.html
比如上面的文章就说到用dri2就可以了,实际上根本原因是现在xvideo的实现,一般来说第一个port都是使用overlay来实现的。
这里又涉及到显卡的硬件了,各家的硬件是五花八门,所以xorg的驱动这里也是很乱,架构也很乱,想统一起来比较困难。这个单开一个标题来说。
目前的显卡基本都是支持3d的,新的显卡是只有3d没有2d的,xvideo这里本来也是可以用texure来实现xvideo,用tuxture来实现xvideo的话
是不会有这个问题的。一般现在的显卡,比如ati的driver,第一个port是overlay,剩下的15个port都是用tuxture来实现的。
用这种port的xvideo来播放视频,然后与composite来一起工作是没有问题的,compiz/berly都是用的composite了。
Xvideo的设计初衷是为了快速的显示图片视频,所以结果是直接输出到屏幕的,这样减少周转,但是和composite的设计就背离了。
Xvideo的硬件加速框架比较简单,不过还是需要专门的一篇文章来讲解。
xvideo这边就目前来说,好像很多接口都已经没有人用了,用的就是XvPutImage,因为Video本身来说解码完成之后就是一帧一帧的数据。
到最后的目的无非就是要把这个frame显示到屏幕上面,中途copy越少越好,能够用到硬件加速就好,硬件的实现多种多样,但是基本的要具备
格式转换,比如yuv->rgb,因为我们的屏幕是rgb的,但是mpeg4或者h264等等解开一般都是yuv格式的,当然yuv格式又分成很多种,硬件不一定
都支持,这个时候就需要软件转换,这个就是copyplanerdata或者copypackedata的工作了,他们都是用来封装数据的,把数据封装成硬件所支持的方式
然后就交给硬件去显示,还有另外一个基本的功能,自然就是缩放了,比如视频原始的分辨率是800x600,但是我们要全屏播放的时候就需要放大,
gpu其实很容易完成这个功能的。无论是pc级别的显卡,还是现在application processor里面的图形加速单元,或者MDP(mobile display processor)
都能轻松的完成这样的工作,这个如果用cpu来算,速度会慢的出奇,当然这个硬件加速需要另外专门的文章来讲,因为解码编码这里需要很多的硬件资源。
各个流程之间的有可以整合的地方,以便让系统发挥最大的性能优势。

关于composite
Xomposite是一Xserver的一个扩展
composite可以完全用软件来实现,比如metacity,xfwm,等等现在基本都可以自己支持composite了,composite下面实际上也可以调用硬件加速,
比如metacity的实现是使用的Xrender。XrenderComposite实际上这个跑到驱动里面去的话,如果有exa就会调用到exapreparecomposite,checkcomposite
composite,donecomposite这些实现,如果要加速composite的话,就需要实现这些exa的扩展了,
composite的运作机制,实际上所有的画面都是先离屏画的,也就是说画在一块内存/显存里面,这块内存是不直接显示的,然后到最后把所有的窗口做alpha blending
然后才显示到屏幕上面,这样我们就可以看到透明效果了。
composite为什么打开之后系统变慢?原因很明显,因为所有的画图结果都不能直接显示到屏幕,要先画到后台,然后windowmanager把当前所有window的buf
做alpha blending之后才显示出来,本身这个框架就导致延迟,然后就是alpha 运算本身很慢了。


关于exa和Xrender的关系
说简单一点就是Xrender是对上层应用的接口,上层的程序都是Xlib写的,可以发起Xrender的请求,他们看到的都是Xrender的接口,当然这个是如果你想用Xrender
这个扩展的话,比如cairo,他绘图的时候就可以选择很多的后端,比如Xlib这个后端使用的就是Xrender,cairo还可以使用很多其他的后端,比如glx(使用的是glitz),



clutter
clutter这个东西是一个做程序的库,可以用3d来做2d的程序,让2d的程序有一些很库的效果,其实就是做动画。如果还是不明白就想想flash做的游戏就可以了。
这个东西其实本来就是做animation用的,所有的东西都可以比对电影,比如timeline,比如actor,比如stage。clutter也有很多不同的后端,比如xlib
比如egl(使用的是opengles1.1或者2.0)或者eglx(使用的是egl+eglx的实现)

cairo
这个东西是一个2d矢量库,用来做2d的矢量图的,比如我们以前画图像tc里面,就会有lineto,moveto,现在cairo看起来也是一样的,不过cairo画出来的是矢量图。
也就是说在画的时候算的。而不是像素的图,如果是像素图的话,放大就会很不清楚了。而矢量图如果放大,实际上就是需要重新算,然后生成一个新的图片,
比如圆,初始半径是5,放大之后,它会重新画一个半径是10的圆,如果实在不清楚,就google一下矢量图和位图的区别。cairo是可以使用


gallium3d
这个东西是mesa的最新发展,主要是解决3d加速的问题了。因为xorg的历史悠久,远远老于linux了,从最早的时候来说,显卡应该是没有任何硬件加速能力的,
我没有见过那么古老的东西,不过sm501这样的多媒体协处理器可能比较像早期的显卡吧,不过好歹sm501还有一些硬件加速,算是2d的。后来慢慢发展显卡有了2d加速单元
就类似sm501了,再后来显卡支持了3d加速,就是离我们不远吧,我们这代人可能没用过有2d加速单元的显卡,好像都是3d的,再后来显卡就只有3d加速单元了,无非
2d是3d的一个特例。到现在显卡支持更多的功能,比如shader,比如硬件解码高清等等。一些人立志改变这种状况,但是实际上这些东西都是商业公司在推动,如果
没有商业公司的支持,就不可能发展了,当然另外一个方面是他们自己要用,开放出来有更多的人来看代码,debug,还有就是3d这里的框架本身就比较复杂了,就算开放出来
大家也还是需要一段时间来理解他们到底是怎么设计的,因为要按照这样的框架来开发驱动。目前支持intel,amd,这些开源的驱动。
就目前的理解来说,无论用什么来操作,比如directx,或者opengl,或者opengles,或者openvg,或者shader,或者其他的,无非都是画一块缓冲区。
然后后来输出如果是xorg,那么就调用xputimage去输出这个缓冲区,xorg这边因为有exa的加速,所以也可以很快的输出,xorg就不会去管理3d的任何东西了,
很多人一直想让xorg的工作更加单纯,只是管理这些窗口,clip region等等。不要搞的和硬件相关。gallium3d的发展趋势来说,看起来是想统一图形加速这一块
无论是3d加速还是2d加速。

目前2d/3d加速的框架
目前用的最多的还是2d使用exa,3d使用dri,当然,exa这边也可以使用dri来实现,所以到最终做事的还是dri这个框架。这样就统一到dri了。
无论是dri还是dri2



硬件加速的实现
硬件加速无非就是写寄存器了。数据传递了,这些。由于硬件实现的不同,对应用程序提供的接口也不同,
大家可以多看看开源的驱动就知道这些东西到底是怎么工作的了。


Xgl的失败
Xgl已经废弃了。个人感觉失败应该说是必然的。
xgl是基于kdrive的,这个的东西更新的相对来说很慢,xorg的代码更新的很快,导致kdrive有些功能已经不能使用,连基本的鼠标处理流程都有问题了。
driver的问题,nvidia等厂家在xds的时候已经明确说明这种框架会导致dual port的驱动很难开发。而xgl的初衷就是为了让这些硬件厂家给linux提供高质量的opengl的driver
这个根本就没有达到
glitz这个东西本来现在是只能使用opengl,而opengles的接口做的很差劲
本来这个东西novel开始是闭源开发的。后来可能是不行所以开源了,然后后来xgl就转向了嵌入式dri/egl这边,但是mesa的egl的扩展一直没有得到驱动厂商的支持,
这样导致两边都不行。

从设计上来说xgl的所有的绘图操作都是使用glitz的,但是glitz本身就是新开发的东西,那个时候未程序,而kdrive自己也有很大问题,而mesa/egl这边也是刚开始做。
基本没有一个东西是可用的,另外xgl自己也是新设计的东西,从头开始实现的。

xgl下面的所有操作都是用glitz,所以就不存在所谓的2d加速了(没仔细研究).因为所有的东西都是走的GL,因为现代的显卡都只有3d加速单元和硬件视频解码单元了,
嵌入式application processor除外。


aiglx
这个东西,感觉没什么用,现在虽然已经成为了标准的glx loader。但是好像就是为了berly/compiz这样的应用而存在的,需要mesa也做扩展。为了好看,就要多做很多工作。


framebuffer
本来显卡比如有512M的显存,但是只有一块显存是对应到我们的屏幕的。这个就是framebuffer了,
没仔细看代码,按理说/dev/fb这个抽象出来的设备应该就是把这块内存抽象成这个设备,然后用户空间可以mmap访问了。


KMS
现在能够操作显卡的程序太多了,而且彼此不知道对方在干什么,比如framebuffer的driver就不知道xorg的driver在干什么,
所以开机的时候framebuffer的驱动初始化,显示东西,然后等到启动xorg的时候这个过程还要再来一遍,等到我们使用ctrl+alt+fx的时候又要关闭xorg这边回到console
其实这个只要做一次就行了,所以有了kms。设置显卡的mode只通过唯一的接口,当然这样会导致操作fb的driver要改,比如目前的framebuffer框架要扩展一下,intel又走在前面
了,毕竟是开源的驱动。然后就是xorg的driver也要改一下,因为xorg不需要做那么多工作了,还有就是内核当然要提供这些kms的接口了。


暂时就说这些吧,硬件加速的实现之后在慢慢写。讲讲kaa硬件加速和xvideo的硬件加速的实现。xorg+exa原理上来说差不多的。
需要一些图片说明:)

国内做xorg或者kdrive相关的文章很少,硬件加速的实现就更少了,想分享出来大家一起学习。

你可能感兴趣的:(xorg 架构 将来 以及一些基本常识浅析)