x window配置

                                                                                一.xorg.conf配置文件

生成xorg.conf文件

关闭x window:init 3 

生成配置文件:X -configure

然后就可以生成xorg.conf.

1. 编译内核时选中内核驱动:

drivers/char/agpgart/VIA chipset

drivers/char/drm/ATI Radeon

2. 安装ati xserver驱动: apt-get install xserver-xorg-video-ati

一.相关文件夹

与X11有关的软件，大多放在/usr及其子目录中。

/usr/bin：存放X Server和不同的X Clients。

/usr/include：开发X Client和图形所需的文件路径。

/usr/lib：X Server和X Clients所需的函数库目录。

/usr/lib/X11：保存多项资源，如字体和文件等。

/usr/lib/xorg/modules：包含驱动程序与多种X Server模块。

/usr/X11/man：保存X11程序编写时的手册说明页。

二./etc/X11/xorg.conf文件

1.ServerLayout

“ServerLayout”Section主要用于建立X Server启动时的外观，如果文件中包含多个ServerLayout Section，则默认会使用第一个ServerLayout Section的设置。

Identifier：此ServerLayout Section的惟一名称。

Screen：“Screen”Section指定的名称，此名称左侧的数字表示在Multi-head环境下的屏幕数量，如果使用标准的Single-head显示卡，则此值为0。在此名称右侧的数字分别代表

屏幕左上角的X与Y绝对坐标，默认值为“0 0”。

InputDevice：在X Server中的“InputDevice”Section名称。通常在此仅有两行设置，即Mouse0和Keyboard0，也就是系统中的第一个鼠标和键盘，而其他的设备大多可以忽略。

radeon支持比较简单的3D建模.
# Option "AIGLX" "True" #打开AIGLX就黑屏

2.Files

“Files”Section用于设置X Server服务的路径，如字体和颜色。

RgbPath：RGB数据库的路径。这个文件定义在X中所有有效颜色的名称，并且指定数值。

FontPath：设置X Server寻找字体时的路径。可以同时使用多个路径，但需用逗号隔开。

作为 Xorg 服务器的一个模块，freetype渲染引擎 的功能包括读取 Truetype 字体信息，如大小、分辨率、编码等，并以之为依据渲染字体。freetype 只负责渲染字体。而查找字体，

则可以由 X服务器、X客户端 或者 字体服务器来 完成。找到字体后，使用 freetype 引擎进行渲染。

X核心字体:X服务器根据X客户端的请求（字符编码），查找字体并进行渲染，然后显示

Xft字体:X客户端自行查找字体并进行渲染，X服务器只负责显示。由于 Xft字体 的渲染在客户端完成，所以它可以动态的加载，而不需要随同X服务器一同启动

字体服务器:当客户端请求字体时，X服务器将请求转发到字体服务器，由字体服务器查找字体，并使用 freetype 引擎渲染，将结果传回X服务器，X服务器进行显示

/etc/X11/xorg.conf 中可以配置X核心字体的搜索路径

Section "Files"

FontPath "/usr/X11R6/lib/X11/fonts/misc/"

FontPath "/usr/X11R6/lib/X11/fonts/Type1/"

FontPath "/usr/X11R6/lib/X11/fonts/Speedo/"

FontPath "/usr/X11R6/lib/X11/fonts/100dpi/"

FontPath "/usr/X11R6/lib/X11/fonts/75dpi/"

EndSection   

3.Module

“Module”Section主要用来告诉X Server应加载哪些模块。这些模块可以提供额外的服务功能，一般并不需要更改此处的值。此处使用的惟一选项为“Load”，它可用来加载模块。

Identifier：设置设备的名称。通常这些名称后面都会加上一个数字，第一个设备的数字为0。例如，第一个键盘的Identifier为Keyboard0。

Driver：告诉X Server应该从哪里加载驱动程序。

Xorg 可以透過 I2C/DDC來得知該寬螢幕所支援的解析度等相關資訊， 因此就能正確偵測出該螢幕所能支援的頻率、解析度。

若驅動程式並未包括 ModeLine 訊息的話， 那麼就要為 Xorg 做些設定才行。

Load "freetype"
Load "glx"

GLX extension 也稱為 libglx，在 X server 中透過 GLX protoco l 對應用程式提供 OpenGL 

context 服務，保留給硬體廠商實做或 Xorg 自行處理。NVIDIA closed source driver 即處理此動作，直接對應到硬體加速呼叫。

# old bitmap font support (no longer needed as of xorg7.x)

Load    "bitmap"

# a collection of X protocol extensions that you want but shouldn't even be loadable

Load    "extmod"

# to load freetype fonts and type 1 fonts

Load    "freetype"

Load    "type1"

# layer below vbe that emus x86 real mode so you can call into vbios

# vesa bios interface for card setup stuff

Load    "int10"

Load    "vbe"

# serial bus over which you speak the ddc protocol to get info from the monitor

Load    "i2c"

Load    "ddc"

# direct rendering infrastructure which makes opengl go fast

Load    "dri"

# glx and glcore implement opengl

Load    "glx"

Load    "GLcore"

# double buffering extension (no apps use?)

#       Load    "dbe"

# 1 of 3 extensions for application automation (unneeded -- most things use xtest from extmod)

#       Load    "record"

- glx   : support for OpenGL rendering;

- dri   : support in the X server for DRI (Direct Rendering Infrastructure)

- vbe   : support for VESA BIOS Extensions. Allows to query the monitor capabilities via the video card;                                                       

- ddc   : support for Data Display Channel, respectively. Allows to query the monitor capabilities via the video card;

- int10 : real-mode x86 emulator used to softboot secondary VGA cards. Should be enabled if vbe is enabled;                                                              

- dbe   : enables the double-buffering extension in the server. Useful for animation and video operations;                                                         

- extmod: enables many traditional and commonly used extensions, such as shaped windows, shared memory, video mode switching, DGA, and Xv;

- record: implements the RECORD extension, often used in server testing;

- bitmap: font rasterizer (so are freetype, and type1 modules).

4.Monitor

“Monitor”Section用于设置系统使用的显示器类型，设置此处选项时应特别留意，因为不适当的设置可能会给显示器造成损害。

以下是此区块的系统默认值，以及可供使用的选项说明：

Section "Monitor"

Identifier "Generic Monitor"

Option "DPMS"

HorizSync 28-51

VertRefresh 43-60

EndSection

Identifier：显示器的惟一名称。在这些名称后面都会加上一个数字，而第一个显示器的代表数字为0（Monitor0）。

VendorName：显示器制造商名称。

ModelName：显示器类型名称。

HorizSync：与显示器兼容的水平刷新频率范围，其单位为kHz。这个设置值会同时指出是否在此显示器中使用特定的Modeline值。

VertRefresh：与显示器兼容的垂直刷新频率范围，其单位为kHz。这个设置值会同时指出是否在此显示器中使用特定的Modeline值。

禁用输入热插拔

Xorg-server 使用 udev 进行设备检测。下面的命令会禁用 udev。

Section "ServerFlags"

Option "AutoAddDevices" "False"

EndSection

警告: 这样会禁用 Xorg 中所有输入设备的热插拔，也就是返回到与 xorg-server 1.4 相同的工作方式。让 udev 自动配置设备更加方便。因此，不建议禁用热插拔！

ModeLine “...” --------->指定显示器的显示模式，很重要。
ModeLine 可以用ddcxinfo-knoppix直接生成。（通过检测你的显卡和显示器）
或者通过gtf 直接计算标准的VESA mode lines。如：
gtf 1024 768 85
则生成：
# 1024x768 @ 85.00 Hz (GTF) hsync: 68.60 kHz; pclk: 94.39 MHz
Modeline "1024x768_85.00" 94.39 1024 1088 1200 1376 768 769 772 807 -HSync +Vsync

5.InputDevice

Xorg 可能会探测键盘失败，这可能是没有正确设置键盘布局(keyboard layout)和键盘模型(keyboard model)。

想看键盘模型、布局、变型和可选件的的完整的列表, 请打开 /usr/share/X11/xkb/rules/xorg.lst

在keyboard InputDevice section中使用XkbLayout选项来改变键盘布局。如果你有一个英文布局的键盘，如下所示:

“InputDevice”Section用于设置鼠标或键盘等输入设备，以便通过X Server提供信息给Linux系统，多数系统至少都存在两个InputDevice Section（鼠标和键盘）。
Section “InputDevice”
Identifier “Keyboard0″ //设备名称
Driver “kbd” //加载的驱动
Option “XkbModel” “pc105″ //设备驱动中option选项，后跟该项的值
Option “XkbLayout” “us”
EndSection

要设置X以使用国际键盘布局，请找到与键盘设置相关的InputDevice段落，并且加入XkbLayout选项来指明你想使用的键盘布局。比如，接下来我们将为你说明如何应用比利时的

键盘布局。你只需要将国家代码替换为你自己的即可。

# cat /dev/input/mouse0

如果你的鼠标已经被检测到，那么就在InputDevice段落中合适的位置填入你的设备。在接下来的例子中，你可以看到我们将设置其它两个选项：Protocol（它列出了可以使用的鼠

标协议――大多数用户使用的是PS/2或者IMPS/2）以及ZAxisMapping（对鼠标滚轮的支持（如果可用的话）。

定义mouse
主设备号可以在/proc/devices找到。每一个物理设备由设备驱动程序控
制且被分配一个次设备号
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol"　 "ImPS/2"　 　　(键位说明)
Option "ZAxisMapping"　 "4 5"
Option "Device"　　 "/dev/input/mice" (如果是ps/2的接口)
EndSection
Emulate3Buttons是否模拟3键鼠标

6.screen
注1：“Screen”Section指定的名称，此名称左侧的数字表示在Multi-head环境下的屏幕数量，如果使用标准的Single-head显示卡，则此值为0。在此名称右侧的数字分别代表屏幕左

上角的X与Y绝对坐标，默认值为“0 0”。
注2：X Server中的“InputDevice”Section名称。通常在此仅有两行设置，即Mouse0和Keyboard0，也就是系统中的第一个鼠标和键盘。

Screen：
“Screen”Section合并了Device和Monitor的部分，以便能够形成成对的设置内容。在xorg.conf中至少需要包含一个以上的Screen Section。
Section “Screen”
Identifier “Screen0″ //“Screen”名称，以便在“ServerLayout”Section中进行参照
Device “Videocard0″ //指定“Device”Section中的名称
Monitor “Monitor0″ //指定“Monitor”Section中的名称
DefaultDepth 24 //默认的色深（Color Depth）位数
SubSection “Display”
Viewport 0 0
Depth 16 //色深位数
Modes “800×600″ “640×480″ //支持的分辨率
EndSubSection
EndSection

EndSection

SectionName包括：
Files　 　 　　文件路径名
ServerFlags　 　 服务器标志
Module　 　 　　动态模块加载
InputDevice　 　 输入设备描述
Device　 　 　　图形设备描述
VideoAdaptor　 　 Xv视频卡描述
Monitor　 　 　 监视器描述
Modes　 　 　　 视频模式描述
Screen　 　 　　屏幕配置
ServerLayout　 　 全面的层叠
DRI　 　 　 DRI特定的配置
Vendor　 　 　　供应商特定的配置

DefaultDepth：默认的色深（Color Depth）位数。

三.显卡驱动配置

dri主要是用来加速本地应用。无论dri还是dri2都是类似的，至于drm是什么，drm是实现dri这个框架，需要内核的支持，这个部分就是内核那个部分的东西了。dri实际上可以看作一个中间层，

所有的人都通过dri来操作资源。
exa
exa是大家认为kaa这个框架很好，所以移植过来放到了xorg里面，改了个名字叫exa，给xorg用的，当然需要xserver和驱动两方面的工作，
对于xorg这边实现的exa，代码在hw/xfree86/exa/下面，驱动里面会注册这些函数，当调用gc的绘图的函数的时候就会判断驱动是否支持
硬件加速，如果支持就会使用硬件的，所谓的xf86-video-xxx这样的驱动，基本都是exa的实现了。
目前用的最多的还是2d使用exa，3d使用dri,当然，exa这边也可以使用dri来实现，所以到最终做事的还是dri这个框架。这样就统一到dri了。

Device

“Device”Section用于设置显示卡的信息内容，在此文件中至少需要包含一个以上的Device Section。如果系统中包含多张显示卡，或一张显示卡上有多种设置值，则可以使用多个Device Section设置。

Identifier：显示卡的惟一名称。

Driver：用来告诉X Server应从何处加载显示卡的驱动程序。

VendorName：显示卡制造商名称。

BoardName：显示卡类型名称。

BusID：显示卡的总线位置，这个选项适用于多显示卡环境。

DRI

Direct Rendering Infrastructure（DRI）是一种接口，它让3D软件可以使用新型显示设备的3D硬件加速功能。除此之外，DRI也能改善2D硬件加速的性能。但通常并不使用这

个选项功能，除非在“Module”Section中打开DRI设置。Direct Rendering Infrastructure (DRI) 为 linux 提供了带硬件 加速的 3D 图形功能。DRI 是一个软件体系结构，它包括

 Linux Kernel, X Window, 3D 图形硬件和 OpenGL 渲染引擎，它们相互配合为 Linux 带来了 3D 图形功能。

Kernel 模块：对应每个 3D 硬件驱动都有一个内核模块这个模块负责 DMA、AGP 内存管理、资 源管理和硬件互斥访问。DMA 传输和 AGP 接口用于 发送图形命令到硬件。

DRI 内核模块位于 /lib/modules/kernel-version/misc/ 目录。DRI 内核模块一般命名为 device.o，常见的 device 如 tdfx, mga, r128 等。

2D XFree86 驱动:对于每种图形卡，都有一个 XFree86 2D (或者 DDX)驱动，它负责初始化、管理 显示和完成 2D 渲染。XFree86 驱动一般在 /usr/X11/lib/modules/drivers 目

录下，名字为 device_drv.o。

3D DRI 驱动：图形卡的 3D 能力通过 3D DRI 驱动来访问,这个驱动将 OpenGL 命 令序列转换成硬件命令，然后它通过内核模块传输命令到硬件。3D 驱动和内核模块基本

上是实现了真个 OpenGL 渲染管道。3D 驱动的大部分工作在用户空间完成，内核模块的工作在内核空间完成。3D DRI 驱动通常在 /usr/X11R6/lib/modules/dri 目录下，名字

通常为 device_dri.so。这些驱动由 libGL.so 库装载，它实现了 OpenGL API。大多数 DRI 3D 驱动都是基于 Mesa 的。

libGL 库:基于 OpenGL 的程序必须与 libGL 链接。libGL 是实现了 GLX 接口和主要的 OpenGL API 入口点。当使用间接渲染时，libGL 创建 GLX 协议消息，通过 socket 将

它们发送到 X Server。当使用直接渲染时，libGL 装载相应的 3D DRI 驱动，然后将 OpenGL 调用分发给该驱动。

libGL 从 /usr/X11R6/lib/modules/dri 目录装载 3D DRI 驱动，也 可通过设置环境变量 LIBGL_DRIVERS_PATH 来改变装载路径。

XFree86-DRI X Server 扩展主要用于 DRI 构件之间的通信，如 X server,kernel module, libGL.so, 3D DRI Driver 等。XFRee86-DRI 模块通常位于 /usr/X11R6/lib/modules/extesions/libdri.a。

X server 的 GLX 扩展负责处理 GLX 协议服务器端的任务，包括设置 GLX-enhanced visuals, GLX context 创建、context 绑定和 context 销毁。当使用间接渲染时，GLX 扩展

解码 GLX 命令包，将它们分发到核心渲染引擎。这个扩展一般位于 /usr/X11R6/lib/modules/extensions/libglx.a。

在间接渲染时，GLCore 模块负责渲染工作。当前使用 Mesa 进行软件渲染，将 来，间接渲染也会使用硬件加速。这个扩展位于 /usr/X11R6/lib/modules/extensions/libGLcore.a。

Section "DRI" 

Group 0 

Mode 0666                           #普通用户也可使用DRI加速

EndSection

Section "Extensions"

Option "Composite" "Enable"         #打开混合模式

EndSection

Glitz是一个OpenGL图像合成库。Glitz提供波特/达夫合成图像和隐面膜包括梯形，三角形，矩形几何图元生成。

X Render(X渲染) 通常比较慢，没有加速。CPU－>系统内存、GPU－>显卡显存APU－>声存比起来，PCI、AGP、PCIE总线是龟速。cpu作框架，gpu做渲染。

EXA (EXcellent Architecture )是針對 client-side rendering 所需的X Render extension 與 Composite extension，提出與 transform operations 都有一定程度的硬體支援，

EXA driver 會以更好的方式去直接驅動。

 Option "AccelMethod" 由預設的 XAA 改為 EXA，"AccelDFS" 則是 EXA driver model 的新特徵，意思是儘可能使用加速的 EXA DownloadFromScreen book.

为了获取你的BusID：$ lspci | grep VGA

01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9600M GT] (rev a1)

这个示例的BusID是 1:0:0.

X调试
在对应域中，通过option设置对应调试开关。如：在xorg.conf显卡device section中添加：
Option “ModeDebug” “Yes”
Option “FallbacKDEbug” “Yes”
即可打开对应调试开关。

ATI显卡支持XAA和EXA两种加速模式，其中EXA方式比较新，性能好出很多。

Option            "AccelMethod"        "exa"        #使用EXA加速模式取代传统的XAA模式

Option        "MonitorLayout"      "LVDS"       #强制LCD，使用CRT不能用此选项

xorg启动后在/var/log/Xorg.0.log中grep到Direct rendering enabled.即表示3D功能激活，Composite enabled表示混合模式打开。

一个PCI外设由BusID(8bit):DeviceID(5bit):FunctionID(3bit)来描述。在xorg.conf 中需用十进制表示。

一般PCI接口的显卡的总线编号为0，AGP接口的显卡的总线编号为1。
单显卡的情况下可以没有BusID这一行。

                                        二.查看硬件瓶颈

X Window从逻辑上分为三层：X Server、X Client和X协议。

最底层的X Server（X服务器）主要处理输入/输出信息并维护相关资源，它接受来自键盘、鼠标的操作并将它交给X Client（X客户端）作出反馈，而由X Client传来的输出信息也由它来负责输出；

最上层的X Client则提供一个完整的GUI界面，负责与用户的直接交互（KDE、GNOME都是一个X Client）。

X协议则是衔接X Server与X Client的通讯协议，它的任务是充当这两者的沟通管道。尽管UNIX厂商采用相同的X Window，但终端的X Client并不相同。

XFree86是X Window系统的一个开源的实现。它主要运行于Unix以及类Unix操作系统上。XFree86在显示硬件（鼠标、键盘以及显卡）与桌面环境（也就是窗口管理器）之间提供了一个Client/Server接口。

Mesa3D是一个兼容OpenGL规范的开放源码函数库，是目前Linux上提供专业三维图形支持的惟一选择。Mesa3D同时也是一个跨平台的函数库

Mesa is a software library for 3D computer graphics that provides a generic Khronos-compliant OpenGL implementation for rendering three-dimensional graphics on multiple platforms

Mesa — OpenGL（开放图形库，Open Graphics Library）API（应用程序编程接口，Application Programming Interface）的一种实现。它为编写由硬件辅助的 2D 和 3D 图形软件提供了标准准则和工具集。
Mesa3D 是一个兼容 OpenGL 规范的开放源码函数库，是目前 Linux 上提供专业三维图形支持的惟一选择。Mesa3D 同时也是一个跨平台的函数库，能够运行在 X Window、X Window with DGA、

BeOS、Linux SVGALib 等平台上。

X server 是指一个程序，它负责在某台机器上接受客户的要求，在屏幕上显示客户请求的图形，并且把消息(键盘，鼠标，窗口消息)通知客户程序。

.Xdefaults设置xwindow

DRI2是下一代的Direct Rendering Infrastructure，具有重定向(redirect) direct rendering功能。在当前，一个程序如果使用了OpenGL窗口，显示内容是直接写到framebuffer里的。这会跟使用了composite 

功能的窗口管理器WM冲突，这是为什么Google Earth在compiz下支离破碎的原因。而通过DRI2，OpenGL窗口内容先被重定向的offscreen memory里，然后由WM负责输出，就不再会有冲突。而DRI2

是基于老的TTM设计的，需要针对GEM作修改。

2D加速方面，EXA 将要取代老的XAA，但EXA也只是xorg server全面转向OpenGL前的一个临时解决方案。XAA不对大量常用2D操作作加速，并且对XRender的加速也支持不够。Intel又提出了 UXA

来取代EXA，当前UXA提供和EXA同样的API，但是利用了新的GEM管理器。

五. 视频硬解码

linux上可用硬解的播放器，分为三家。XBMC可调用xvba硬解，大名鼎鼎的mplayer，可调用vaapi，和花见花开的vlc，这好像是最好的。
XBMC注意要添加第三方源来安装,不过有现成编译好的版本
Mplayer不含任何vaapi支持，内置了vaapu支持。支持vaapi的是mplayer-vaapi，需要自己编译的.据我所知它是性能最好的。

Ubuntu官方源中的Mplayer不支持VA-API，Ubuntu 12.10, 12.04 or 11.10用户可以通过下面的命令安装支持ＶＡ-API的Mplayer.

sudo add-apt-repository ppa:sander-vangrieken/vaapi

sudo apt-get update

sudo apt-get install mplayer-vaapi

安装后打开你的播放器，

打开Preferences，如 ( SMPlayer: General Video > Output driver) 

设置video output driver 为 "vaapi"

vlc，最傻瓜的选择。最新的vlc 已经预先内置了vaapi支持，所以你直接在vlc里输入与解码器选项卡，打开硬件加速，就可以硬解了。如果是从命令行启动vlc可以看到using va-api 0.32 version等等类似的信息就行了。

六.x window原理讲解

GLX是X Window的一个扩展，专门为X Window实现3D渲染而开发的一个扩展，通过和 X server 打交道来进行渲染的，因此又叫作间接渲染（indirect render）。为了实现X Window 与OpenGL(Mesa)的结合，制定了GLX标准。

Xlib
 X11 有很多个模块。Xlib 是它的基本模块，提供了一些基本的图形访问接口。此外 X11 还可以有一些列的扩展接口，只要符合 X11 的扩展规范，就可以。X11 上的 OpenGL 就是通过 X11 的扩展来衔接的。

DRM & DRI
 DRI 全称 Direct Rendering Infrastructure。X11 是采用 C/S 架构的，客户端的任何操作都需要和服务器进行通讯，在实时的 3D 渲染上性能无法接受。DRI 在 X11 上能够允许直接访问硬件渲染器（显卡），从而直接将 3D 图形渲染到屏幕上，绕过 X11 ，提升性能，这种叫作直接渲染（direct render）。DRI 为上层 3D 库提供访问底层硬件的接口。DRM 全称 Direct Rendering Manager，直接渲染管理器，是真正操作硬件的层次。各个硬件厂商负责提供各自硬件的 drm 模块（开源的提供源码、不开源的提供二进制文件）。DRI 通过调用 DRM 的接口来实现上层 3D 图形库的接口。DRI 的源码则在 Mesa 中。

Mesa
Mesa 自身提供一套纯软件的 OpenGL 实现，能在各个平台运行 OpenGL 程序，不过速度非常慢。 Mesa 会根据系统平台的 dri 和 drm 情况调用硬件的 OpenGL 实现，这时就是硬件的 3D 加速:3D app --> Mesa(OpenGL API) --> dri --> drm --> hardware。

SDL
 SDL 是一个开源跨平台的图形库，它小巧、简单、快速，提供在 linux 上简单的 GUI 接口。

Mutter Window Manager
 X11 只是提供了一些基本的 GUI 元素.对于窗口如果显示、窗口移动了怎么办、窗口尺寸改变了又怎么办、多个窗口重叠在一起怎么显示等等，X11 是不会管的。需要窗口管理系统的软件来管理。一般 X11 上的窗口管理系统都是基于 Xlib 开发的。

Clutter
 Clutter是一个跨平台的图形库，能够支持 OpenGL。Mutter Window Manager 使用的图形库是就是 Clutter。Clutter 采用 glib 提供的 gobject 实现面向对象设计，采用多种 backend 的架构，实现了跨平台。在 linux 上使用的 backend 是 GLX 和 X11 。

Cogl
 在 Clutter 中使用的 OpenGL 接口。源代码包含在 Clutter 中。

Screen
Screen 的层次在 Display 之下，是 X server 显示管理的次级单位。一个 Screen 对应一个根窗口（root window），根窗口的大小与 Screen 相同。如果在命令行执行 "X" 的话，启动了 X server，这时在屏幕上看到一个单调的桌面，以及一个 "X" 形的鼠标，不过因为没有启动 window manager，所以什么都不能做，只能动动鼠标。这时你看到的这个单调的“桌面”正是根窗口。

Pixmap
 这个是 X11 上另一个可以绘制图像的东西。它和上面 Window 的区别在于：Window 的绘制是直接在屏幕上的，而 Pixmap 的绘制是离屏的。

先行解釋相關的術語。

運作於 kernel mode 的部份有：DMA (Direct Memory Access)、AGP memory，以及 MMIO (Memory-mapped I/O)

libGL.so：處理 GLX protocol 的細節，並載入 DRI driver

libGL：這是 API (Application Programming Interface) 層面的部份，也是決定 OpenGL 應用程式在執行時期的行為。

就目前的設計來說，分成：

from Mesa：虛擬的 GLX 實做，可用於任何 X server 實做；

from XFree86/DRI：真實的 GLX 實做，GLX protocol encoder；

from specific Vendor (像是 nVIDIA)：真正的 GLX，不走 DRI 也不走 Mesa，直接存取硬體。

GLX extension 也稱為 libglx，在 X server 中透過 GLX protoco l 對應用程 式提供 OpenGL context 服務，保留給硬體廠商實做或 Xorg 自行處理。NVIDIA closed source driver

 即處理此動作，直接對應到硬體加速呼叫。

DRM (Direct Rendering Manager)

本質是kernel module (menuconfig 裡面 character device -> drm)

管理對硬體的操控要求

補充一下，glxinfo 會顯示

GLX protocol version

OpenGL version

DRI version

DirectFB是图形API存在于Frame Buffer层之上与高级图形管理层如GTK+等之下的。它可以以很小的系统资源占用来提供图形硬件加速功能，提供类如多路a通道渲染模型等高

级图像操作。它不修改Linux内核，除了标准C库没有其他库的依赖。应用在了基于Linux系统的DTV显示系统的研发和其他有关Linux显示界面的项目上。支持市面上绝大多数

显示卡，支持键盘、鼠标、遥控器、游戏手柄、触摸屏等输入设备。支持JPEG、PNG、GIF、mpeg1/2、AVI、MOV、Flash、Video4Linux、DirectFB bitmap font和TrueType等

音视频文件和字体。

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

前面了，毕竟是开源的驱动。然后就是xorg的driver也要改一下，因为xorg不需要做那么多工作了，还有就是内核当然要提供这些kms的接口了。
3D加速

DRI2 是对直接渲染设施（DRI）的重构，它被用来实现重定向直接渲染。当前，当一个应用程序想绘制一个 OpenGL 窗口，它直接访问屏幕缓存。在 DRI2 里，它将会被重定

向到离屏缓存，这样合成管理器便可以做出精美的视觉效果。这显然依赖于一个稳定的内存管理 API，所以当 GEM 引入时它不得不做相应改变，因为 DRI2 是在 TTM 首先

被实现后才设计出来的。

DRI，是一个允许在安全和高效的方式下直接访问显卡硬件的架构。它包括对X服务器的改动，以及对几个客户端库和内核的改动。DRI的第一个重要应用是创建快速的OpenGL

实现。

DRM（Direct Rendering Manager——直接渲染管理器）是Xorg的一个改进，它通过增加直接渲染所必要的内核模块来为显卡增加3D加速功能。 

                                                      三.查看系统瓶颈

一.南北桥

北桥芯片负责与CPU的联系并控制内存、PCI-E数据在北桥内部传输，提供对CPU的类型和主频、内存的类型和最大容量、AGP/PCI-E插槽、ECC纠错等支持，还集成

了显示核心；北桥通过前端总线和CPU相连。南北桥结构是通过PCI总线来连接的，常用的PCI总线是33.3MHz工作频率，32bit传输位宽，所以理论最高数据传输率仅

为133MB/s。南桥芯片负责I/O总线之间的通信，如PCI总线、USB、LAN、ATA、SATA、音频控制器、键盘控制器、实时时钟控制器、高级电源管理等。北桥负责CPU

和内存、显卡之间的数据交换,南桥负责CPU和PCI总线以及外部设备的数据交换 。

二.前端总线

外频指的是CPU与主板连接的速度，而前端总线的速度指的是数据传输的速度，由于数据传输最大带宽取决于所有同时传输的数据的宽度和传输频率，即数据带宽=

（总线频率×数据位宽）÷8。

100MHz外频特指数字脉冲信号在每秒钟震荡一亿次；而100MHz前端总线指的是每秒钟CPU可接受的数据传输量是100MHz×64bit=6400Mbit/s=800MByte/s（1Byte=8bit）。

主板支持的前端总线是由芯片组决定的，一般都带有足够的向下兼容性。

外频是CPU乃至整个计算机系统的基准频率,计算机系统中大多数的频率都是在外频的基础上，乘以一定的倍数来实现，这个倍数可以是大于1的，也可以是小于1的。

主频就是CPU的时钟频率；倍频即主频与外频之比的倍数。主频、外频、倍频，其关系式：主频=外频×倍频。    

三.GPU介绍

GPU的流式数据并行模型保证在多数据流上执行相同指令，以nVidia G80核心为代表的GPU包含1-16个多处理器（multiprocessors），每个多处理器包含8个流处理器（stream processors）

和2个专用于执行如平方根倒数等标量运算的特殊功能单元（special functional units）。其中一个多处理器内部的所有流处理器以SIMD（单指令多数据）的结构执行同样指令，而不同的

多处理器可以以MIMD（多指令多数据）结构执行不同的指令。从线程角度讲，每个多处理器可并行运行768个活动线程，即包含16个多处理器的GPU可并行运行12288个活动线程。从存

储器角度讲，每个多处理器有16 KB可读写共享内存（shared memory）、8 KB只读常量内存（constant memory）、8 KB只读纹理内存（texture memory）和8192个寄存器（Registers）。

图2表示了这种架构。在图像处理的GPU加速算法设计中，如何针对这种架构分割像素或图像块以映射到并行线程进行处理，再经由多级存储器将被处理的像素或图像块重新组合成结果

图像是高效算法设计的关键。

开始在GPU上计算之前，需要加载输入数据到GPU的设备内存（显存）中，计算过后，如果CPU需要计算结果，就要从GPU把结果数据读回CPU。与此相对，在CPU上执行程序不需要这些额

外的操作。

X.org和XFree86这样的开源X实现中

GART最初是设计允许图形芯片直接从系统内存读取结构特征，使用地址转译将系统中的配置收集到一个临近的域中，这个域被映射到一个图形设备可以“看”到的地址。但是GART也被Linux内核程序

员用来让传统32位PCI设备能够访问可寻址范围之外的系统内存区域。这是通过编程让设备能够在受GART控制的显存区域内工作、然后使用GART将这个地址转换为真实的目标地址（4GB以上）来实现的。

It depends on which memory to be accessed by GPU engines:
1) For local video memory, current GPU just directly go through MIU(Memory Interface Unit) to frame buffer without any address translation;
2) For PCIe memory, in most of cases there is small TLB for address translation because GPU need translate incoming virtual address to physical system memory address by looking up GART;

PCI/VGA Palette Snoop（PCI/VGA调色版探测） 
选项：Enabled，Disabled 
此特性仅用于图形卡接口上的附加设备，比如MPEG子卡等。通过调色版探测可以纠正帧缓存的数据，并能把它们同步发给附加设备和主显示卡，避免添加子卡后产生黑屏现象。

因为GART（Graphic Address Remappng Table，图形地址重绘表）过大会导致系统出错，建议AGP区域内存容量不要超过64-128MB。

A computer system having a core logic chipset that functions as a bridge between an Accelerated Graphics Port ("AGP") bus device such as a graphics controller, and a host processor and computer system memory 

wherein a Graphics Address Remapping Table ("GART table") is used by the core logic chipset to remap virtual memory addresses used by the AGP graphics controller into physical memory addresses that reside in the

 computer system memory. The GART table enables the AGP graphics controller to work in contiguous virtual memory address space, but actually use non-contiguous blocks or pages of physical system memory to store 

textures, command lists and the like. The GART table is made up of a plurality of entries, each entry comprising an address pointer to a base address of a page of graphics data in memory, and feature flags that may be 

used to customize the associated page. The core logic chipset caches a subset of the most recently used GART table entries to increase AGP performance when performing the address translation. The core logic chipset 

uses a two-level GART cache comprising a plurality of first-level GART caches and a common second level GART cache. Each of the plurality of first-level GART caches are coupled to a respective interface in the 

computer system and effectively de-couple the different interface GART address translations so that GART cache thrashing and cache arbitration delays are substantially reduced. Separate decoupled first-level GART

 caches for each interface allow concurrent GART address translations among the different interfaces. Individual first-level GART caches may be fined tuned for each associated interface