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

最新推荐文章于 2024-01-22 15:07:02 发布

soulxu

最新推荐文章于 2024-01-22 15:07:02 发布

阅读量2.4k

点赞数 1

分类专栏： XWindow 文章标签：框架工作扩展 animation shader 嵌入式

XWindow 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

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

原文：http://blog.chinaunix.net/u1/40978/showart_1968756.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的工作了，他们都是用来封装数据的，把数据封装成硬件所支持的方式然后就交给硬件去显示,还有另外一个基本的功能，自然就是缩放了，比如视频原始的分辨率是800×600,但是我们要全屏播放的时候就需要放大，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的接口了。