Linux Graphics Base Knowledge

• Linux本身没有图形界面,Linux现在的图形界面的实现只是linux下的应用程序实现

图形界面并不是linux的一部分,linux只是一个基于命令行的操作系统,linux和Xfree的
关系就相当于当年的DOS和 WINDOWS3.0一样,windows3.0不是独立的操作系统,它只是DOS
的扩充,是DOS下的应用程序级别的系统,不是独立的操作系统,同样 XFree只是linux下的
一个应用程序而已.不是系统的一部分,但是X的存在可以方便用户使用电脑.WINDOWS95及
以后的版本就不一样了,他们的图形界面是操作系统的一部分,图形界面在系统内核中就
实现了,没有了图形界面windows就不成为windows了,但linux却不一样,没有图形界面lin
ux还是linux,很多装linux的WEB服务器就根本不装X服务器.这也WINDOWS和linux的重要
区别之一
 

Read Full Post »

Linux Graphics Driver Stack Explained

Knowledge for Linux Graphic Driver Stack

You Linux Video Card driver is not a single blob of code. As with any sufficiently large piece of software, things need to be broken up into discrete components for both technical and maintainability reasons.  And, there is no doubt a complete graphics stack is large: the AMD Catalyst driver is a 93MB download.  That’s over one hundred Mega bytes of executable code and supporting data.  In that humongous pile of bytes are roughly half a dozen different components working together to deliver your polygonal needs, without counting the configuration tools.  This, unfortunately, is not common knowledge.

In the open source world, our drivers are much more svelte, partly because less features are supported, and also because application-specific optimizations are omitted.  Unlike the proprietary drivers, however, the boundaries of separation are clearly visible.  In respect to “driver” code that is specific to a particular hardware, there are, more or less, three separate components involved:

• X display driver
• Mesa DRI driver
• Kernel DRM driver

Indeed, in true UNIX fashion, all of these are actually worked on as completely separate projects, albeit with significant overlap in the personnels involved.

1. DDX: People’s Favorite Barking Tree

When the words “Linux video card driver” are invoked, the DDX is what people typically think of.  And, for good reason: historically, when configuring X11, the DDX was one of the few things that had to be configured by the user, and could be selected. This is your radeonhd, radeon, nv, and intel.

The main function of these drivers is to provide mode setting: that is, selecting the screen resolution, colour depth, turning outputs on and off, etc. The X server uses the DDX to perform basic, essential hardware manipulation so that you can have a graphical display at all.  Each DDX is hardware-specific: indeed, it stands for Device Dependent X (but this trivia is not very important.)

A DDX also provides hooks that allow the X server to offload certain drawing operations to the GPU so that they can be accelerated.  XAA, EXA, and UXA all fall under the DDX’s domain, in addition to Xv.  The former group is responsible for things like moving windows around your desktop, scrolling a website in your favourite browser, and compositing desktop effects.  The latter handles video rendering.

To summarize, everything 2D is the domain of the DDX.  And, in simple terms, it is its only domain.  If you are looking for 3D acceleration, this is not the tree to be barking up at.

2. Mesa DRI Driver: The Invisible Hero

OpenGL is the method with which applications achieve 3D rendering under Linux.  Unfortunately, but for good reasons, it is not possible to go from an OpenGL function call to manipulating hardware states in a single step.  Multiple translations must be done under the hood to convert those calls into something that the GPU can understand.

Mesa is largely divided into two parts: an OpenGL compatible library stack that applications can call into, and DRI drivers that translate Mesa-internal instructions into forms that the video hardware can understand and execute

After a call is made to the Mesa library and it has been translated into a GPU-specific language, the resulting operations need to be sent to the hardware for execution.  Mesa, however, cannot do this without help as it lives in user space:  only kernel space code is allowed to touch hardware directly.  Note that DDX is one of very few exceptions to this rule: it is technically user space code but allowed direct hardware access, for better or worse.

Unfortunately, sending these instructions through the DDX, and hence X, is not fast enough.  This point finally brings us to…..

3. DRM: Bridge to the Hardware

The final piece of the driver stack is the Direct Rendering Manager.  Oversimplified, it exposes certain features of the hardware with an abstraction layer to user space such that applications like Mesa can make use of a GPU more efficiently.

It is also the job of the DRM layer to provide measures that ensure multiple applications that require working closely with the hardware to not step on each other’s toes.

DRM drivers are Linux kernel modules, which are accessed by user space through libdrm.

———————————————————————

Video hardware rarely change completely from generation to generation.  This means that the same code is often times used to operate GPUs from multiple generations.  Understanding which version of which component you need can occasionally become a messy affair.

To draw an example from the Radeon world, R3xx (Radeon 9xxx) and R5xx (Radeon X1xxx) GPUs share a similar 3D engine, but the mode setting engines are drastically different.  Therefore, while you can use the same Mesa DRI driver on both (r300_dri.so), radeonhd will not work on the former.  As for DRM, radeon (note that there is a kernel module and a DDX bearing this name) takes care of everything. (There are, of course, oddities from those generations that do not fit in to this generalization.)

Furthermore, there is currently a push in Linux to move video mode setting into the kernel (Intel is already there).  Kernel Mode Setting, more commonly referred to as KMS, brings the user- and kernel-space separation back to X, relieving the responsibility of hardware manipulation from the DDXes and putting it solely in the DRM drivers.  The details of this topic will—perhaps—be explored another time.

———————————————————————-

To Be Continued……….

 

Read Full Post »