Graphics systems for "original" Linux environments and AMD graphics driver programming (1) Introduction to graphic systems in the--linux environment

In the Linux/unix environment, the earliest graphics system is xorg graphics system, xorg graphics system through the expansion of the way to adapt to graphics and desktop graphics development needs, but with the development of hardware and software, especially the development of embedded systems, xorg appears large and backward. The open source community has developed a number of new graphics systems, such as the Wayland graphics system.

Due to the complexity of the graphics system, the 3D graphics itself, and the historical reasons, the source code of the graphics system under Linux is very large and complex, and the lack of learning materials (all the sources analysis or driver programming books rarely introduce graphics drivers). In a series of subsequent articles, I will make a brief introduction to some of the issues from the point of view of AMD hardware programming, of course, this kind of introduction is very elementary, and is intended to be helpful to some beginners.

The code combined with kernel DRM, xorg, and Mesa is about the same size as the entire Linux kernel. And the complexity of the GPU on the modern graphics card can be somewhat comparable to the CPU, and from the programmer's point of view, the operating system (CPU driver) contains many features that can be found on the GPU driver. For example, the GPU has its own instruction system, shader programs (such as GLSL, HLSL, CG, and so on) need to be compiled into the instruction set of the GPU before it can run on the GPU, the 3D driver conforming to the shading Language specification contains a compiler. 3D applications need to use a lot of memory, and the GPU needs to access the memory when it is being used, and the GPU uses the same mechanism as the CPU page table when accessing the memory. Also, there are similarities between the GPU and the CPU on the interrupt system. Some of the following will be a brief introduction to these questions.

Traditionally, Linux is a macro kernel, most of the device drivers are included in the kernel, so you can see the kernel code is the largest part of the drivers directory, if you download a kernel source from kernel.org, compile directly, compile the time of most of the compilation device is consumed in the driver.

Micro-kernel operating system, device drivers are not part of the kernel. This does not discuss the differences between the microkernel and the macro kernel or their pros and cons. But for debugging convenience and some other reasons, some of the drivers on the Linux operating system are outside the kernel. A major category is printers, scanners, such as devices, the current printer scanner is usually connected to the computer via a USB interface, for these devices, Linux drivers, in addition to the USB core part of the kernel, the printer scanner itself is the driver is outside the core. The printer above Linux uses the cups system, and cups runs outside the kernel, and its drivers are developed in accordance with the Cups interface. The scanners on Linux use a sane system running outside the kernel, and its drivers are in the form of a dynamic link library. Another type of external drive is the driver of the graphics system, due to the graphics system, the graphics card itself is more complex, and for some historical reasons, the graphics system is driven outside the core core, and the graphics card driver is the most important part of the core outside.

On the newest page of the wiki entry "free and Open-source graphics device driver", there is a good illustration of the evolution of the graphics system in the Linux environment, which is described directly using the diagram of this page./HTTP En.wikipedia.org/wiki/free_and_open-source_graphics_device_driver.

The first video card only has the basic display function, can become the display controller or the frame buffer device, for such a display controller, the current Linux kernel support for the performance of Framebuffer driver, The support for the Xorg section is a driver named Fbdev.

Figure 1

A 2D acceleration component is gradually added to the graphics card, in which case the following drivers are shown. The architecture in this case is still relatively simple.

Figure 2

With the need for 3D graphics display and operation, graphics graphics function of the video card appears, this time need to have a special 3D driver to deal with the GLX driver, here Notice that X server is still in a central node location, whether it is X11 program or 3D OpenGL program, all through the X server to the bottom. It is also noted that the 2D driver and GLX driver of X have been called directly to the hardware so far, not through the kernel. On the 2.6 version of the kernel system, you can still see the X 2D driver has access to the hardware Mmio and CP two sets of code, MMIO is the case here, the video card register directly exposed to the outside of the 2D driver (and GLX driver, there is no longer this).

In this case the structure is still relatively simple, however this situation has a big problem, read the X server code (or refer to this article "X Window System Internals" http://xwindow.angelfire.com/ It should be known that x server is single-threaded (about multi-threaded x server, can be Google to some of the message discussion records), the main function completes the system initialization has entered a loop, waiting for the client program to connect, After a client program sends the data after the other clients can connect, the OpenGL client program every time to request hardware must go through X server, and then by X server "on behalf of" OpenGL program into the hardware, for the scene of a slightly complex 3D application, This frequent interaction with X server is difficult to guarantee the real-time 3D rendering.

In view of the above problems, the DRI mechanism is introduced, under which the OpenGL program's request for hardware does not go through X server, but it interacts directly with the hardware itself. The whole process is this: Before the drawing, OpenGL program to the kernel to a piece of render target and tell X server, and then OpenGL program without x server and directly call into the kernel request hardware rendering operation, and render the result to the requested render target, after the rendering is finished, OpenGL program notifies x server that the render target has changed, the corresponding screen of the window area needs to be updated, X server receives this notification, a re-window mixing work (the current code is provided by the Exa composite function). At this time, as shown, GLX driver is replaced by DRI driver, and DRI driver is no longer an X server and is directly an OpenGL program. In addition DRI (formerly GLX) does not operate the hardware directly, but uses the kernel DRM to drive the operating hardware, which provides the hardware access channel and access mechanism. On the current system, 2D driver is present in xorg in the form of Exa 2D acceleration Drive, and DRI driver is in Mesa.

Figure 3

Then added support for the remote 3D client AIGLX, this part of the function and the original Utah GLX have similarities. AIGLX can refer to the wiki page (Http://en.wikipedia.org/wiki/AIGLX).

Figure 4

X server is so large and complex that it is not necessary to make it look like it is expanding. The open source community put forward a more concise Wayland graphics system, in the "Unveiling Wayland Veil (a) (ii)" Two articles in the face of Wayland, the reader can click the following address:

Http://www.ibentu.org/2010/11/06/introduce-to-wayland-01.html

Http://www.ibentu.org/2010/11/06/introduce-to-wayland-01.html

Figure 5

In these two articles, a scene is described: Click a button on a graphics program. Under the X-graphics system, X's Evdev drive captures this information, X is told that the application needs to be rendered, and then X Server queries the window that needs to be rendered, and then notifies the "mouse click" event to the X program for the window that needs to be rendered, and the X program receives the notification and then tells X server "How to Render", the X server receives "How to render" the message after rendering (2D case X/exa itself, 3D without first notifying X server, using DRI to complete the drawing and the application tells the X render has completed), complete the notification X "composite" Extensions are mixed, X's composite expands to the mixed request and informs the X server that the mix is complete, which has two-way communication between x server and x client and x server and X composite, both of which are time consuming and because X The server notifies the X composite that there is a need to overlap the window, the shear calculation of the covered window, etc.-but these are not required by X composite, so there is some extra time spent.

In Wayland case, the server is mainly composite, the application all use DRI Direct rendering mechanism, the completion of the Notification server (composite) mixed, the structure is very simple and efficient.

In addition, the request for the window has also changed, in the X DRI, X11 and 3D programs need to the X Server request window, at that time X server acceleration operation must rely on a separate Exa driver (cannot directly call OpenGL acceleration), later Mesa made some changes, In the Wayland environment, application directly requests the drawing window through EGL, GLES driver to the kernel DRM, where composite can be directly called opengles for acceleration without the need for a separate 2D acceleration drive.

Also notice that there is a KMS inside the kernel, the full name is kernel mode setting (kernel mode setting, setting display resolution and so on), as mentioned earlier, the early video card register is a direct burst to the nuclear external drive, Until now the Exa kernel code still has MMIO and CP two operation mode, early x in the mode setting when the direct write register to operate, and then the kernel introduced KMS (before the Wayland already), The out-of-the-way driver can then perform mode operations by invoking the KMS interface without needing to know the hardware details.

The above refers to the operation of the Composite,x composite as shown:

Figure 6

In the past, the X11 client was directly on the display area, and now X11 the client window on off-screen memory, compositor out the contents from the video memory and eventually mixed it into the display area. x inside and composite operation related extensions have damage, render, composite, these three descriptions refer to the following information:

Http://cgit.freedesktop.org/xorg/proto/compositeproto/plain/compositeproto.txt

Http://cgit.freedesktop.org/xorg/proto/damageproto/plain/damageproto.txt

Http://cgit.freedesktop.org/xorg/proto/renderproto/plain/renderproto.txt

For the introduction of x composite readers can refer to the following information:

Keith Packard. Design and implementation of the X Rendering Extension

Matthieu Herrb, Matthias Hopf. New evolutions in the X Window System

Andy Ritger. Using the Existing xfree86/x.org Loadable Driver Framework to Achieve a composited X Desktop

The graphics system architecture for the current Linux environment is as follows:

Figure 7

Some of the content here has been described earlier, it should be noted that the X server Exa drive part of the Glamor,glamor direct call to Mesa inside, the past Exa Drive is a separate driver, through the DRM call operation Hardware, and due to the change of Mesa, X can call Mesa's interface directly like Wayland Composite.

The following description will be for the Fedora 16 operating system, the Fedora 16 system and now the latest system (Figure 7) has a certain difference, the discussion of some of the following issues mainly use Figure 4. In the following blog, a simple description of the Fedora graphics system kernel, X, Mesa, and then start to introduce the drive to the AMD Graphics hardware module (function) programming.

Graphics systems for "original" Linux environments and AMD graphics driver programming (1) Introduction to graphic systems in the--linux environment