Graphics system for "original" Linux environments and AMD graphics driver programming (2) Introduction to--framebuffer, DRM, Exa, and Mesa

1. Framebuffer

The framebuffer driver provides a basic display, and the framebuffer-driven hardware is a display controller and frame cache (one piece in the system main memory or graphics memory). The framebuffer driver provides the application with a/DEV/FBX device interface that the application implements to the display controller and frame cache by reading and writing to this device node.

The following program shows the process of operating the Framebuffer node in an application operation. Running this program will display a square above the screen (error checking code is omitted here).

1 #include <stdio.h>
2 #include <unistd.h>
3 #include <fcntl.h>
4 #include <sys/mman.h>
5 #include <sys/ioctl.h>
6 #include <linux/fb.h>
7
8 int main ()
9 {
FD int;
One-by-one struct fb_var_screeninfo vinfo;
A struct fb_fix_screeninfo finfo;
size_t screensize = 0;
+ int location;
char *fbp = NULL, *ptr;
int x, y, x0, y0;
i,j int;
int ret;
+
FD = open ("/dev/fb0", O_RDWR);
if (FD < 0) {
fprintf (stderr, "Error open fb0\n");
return-1;
+ }
ret= IOCTL (FD, Fbioget_fscreeninfo, &finfo);
if (Ret < 0) {
fprintf (stderr, "Get fixed screen info error\n");
return-1;
}
ret = IOCTL (FD, Fbioget_vscreeninfo, &vinfo);
if (Ret < 0) {
fprintf (stderr, "Get variable screen info error\n");
return-1;
*
ret = IOCTL (FD, fbiopan_display,&vinfo);

if (Ret < 0) {

Notoginseng fprintf (stderr, "Pan display failed\n");
Return-1;
The
Screensize=vinfo.xres * vinfo.yres * VINFO.BITS_PER_PIXEL/8;
FBP = (char *) mmap (NULL, ScreenSize, PRO t_read| Prot_write, map_shared, FD, 0);
if (fbp = = map_failed) {
fprintf (stderr, "mapped error\n"),
Return-1,
,
x0 = $;
y0 = 200;
to ptr = fbp + y0 * finfo.line_length + x0 * VINFO.BITS_PER_PIXEL/8;
for (i = 0; i < i++) {
char* tmp_ptr = ptr;
Wuyi for (j = 0; J < + j + +) {
*tmp_ptr++ = 0;
*tmp_ptr++ = 255;
*tmp_ptr++ = 0;
*tmp_ptr++ = 0;
56}
+ ptr + = finfo.line_length;
58}
Munmap (fbp,screensize);
Close (FD);
return 0;

The operation of the application on framebuffer is done primarily through the IOCTL and mmap. The mmap maps the memory to the user space. 25 rows and 30 rows get the current framebuffer driver's "Fixed parameters" and "Variable parameters", these two parameters contain the current display control of some of its information, the variable parameter is mainly the current resolution information, the fixed parameter is mainly the current memory address. The 35-row fbiopan_display is typically used for double-buffering, but there are other meanings to use here, which are discussed later when discussing DRM's framebuffer. 41 Line memory mapped out, 51-59 lines operation of the video memory, the top left to draw a coordinate of (200,200), edge length of 100 square.

Applications can use these IOCTL because the kernel provides the appropriate interface, the Linux kernel device driver related books will discuss the framebuffer driver, here does not discuss how to write a framebuffer driver.

2. DRM driver

In the previous blog post, Figure 4 is the DRM driver inside the kernel, notice the difference with Figure 3, the individual FB driver has not been, but has been assembled into the DRM driver inside. In some embedded systems that only require an in-place display, a separate framebuffer driver is still used, while the kernel and display-related functions are integrated into the DRM driver for drivers with AMD and Intel that are accelerated in the kernel. In Amd/intel graphics +xorg+3d This configuration of open source Linux system, Xorg is not used, but the system still has/dev/fb0 such device node, if we in the desktop environment "Cat xxx >/dev/fb0", the system will not change. However, if you change the xorg.conf driver to "Fbdev" and restart Xorg, you can see a change in the action (about xorg.conf can refer to "man xorg.conf" or view this page). or switch to console terminal "CTRL+ALT+FN", and then run the same command, you can see the contents of the screen has changed, in the first section of this post the program has a fbiopan_display call, This call causes the memory address of the CRTC point of the video card to change and the current display area is switched to the corresponding area of the FB0 device node, so the above program runs even in the X desktop environment and can see the screen change. This suggests that, in the case of a nuclear external x drive, the framebuffer driver is not used by the nuclear external x driver (in fact, the DRM-driven Frambuffer device is only used by the kernel) and does not use the framebuffer after X starts running. The content of the memory that is managed is used as a display output instead of a different piece of memory.

The graphics drivers for the kernel on the current Linux system are called DRM drivers, and on the usual Linux kernel distributions we use the Lsmod command to view the kernel modules and see information similar to the following:

Radeon 933054 3

TTM 45600 1 Radeon

Drm_kms_helper 22468 1 Radeon

DRM 162230 5 Radeon,ttm,drm_kms_helper

I2c_algo_bit 5055 2 I2c_gpio,radeon

The machine uses AMD's Radeon graphics card, which shows the current system core and graphics driver-related modules, the DRM module is a kernel DRM-driven infrastructure, all DRM graphics drivers will load this kernel module, TTM is the TTM kernel management mechanism, DRM_KMS_ Helper is the basic framework code of kernel mode, I2c_algo_bit is the module used for operating the I²C device on the graphics card, the I²C device on the graphics card mainly includes the Connector,encoder and the PLL clock chip. The DRM kernel-driven code is DRIVERS/GPU/DRM below the kernel source directory. After the DRM driver is loaded, the following device nodes are generated under the/dev directory:

/dev/char/226:0. /dri/card0

/dev/char/226:64. /dri/controld64

/dev/dri/card0

/dev/dri/controld64

Where/dev/dri/card0 is the interface to operate the GPU, the command is sent through the device node. /DEV/DRI/CONTROLD64 is a KMS-related device node.

The main part of the graphics drive under Linux is the out-of-core part, which includes the xorg Exa Drive and the Mesa 3d Drive, the Exa is the traditional 2D acceleration frame, and the Mesa 3d drive is hardware acceleration for 3D drives. For historical reasons, on Fedora 16 and earlier and later systems, even if the hardware does not contain a separate 2D part 2D function is implemented by 3D parts, the 2D drive and 3D are still separate.

3. Exa Drive

The early 2D acceleration Drive uses the XAA, Kaa architecture, but with the addition of the composite extension, the new Exa framework has been created, Exa removed the original 2D drive in the triangle drawing, line drawing and so on some now useless function, Instead, there are three acceleration functions: rectangular Fill (Solid), copy-screen operation (COPY/BLT), and mixed operation (Composite).

The XFREE86 server 4.x Design (DRAFT) Article details the interfaces that the xorg driver needs to provide, and the Exa driver is added and compiled into the xorg drive in the form of an extension. In the following blog post will introduce the Exa driver interface, and use the Radeon Exa driver to describe the graphics driver programming process.

4.3D Drive

In the Linux environment, we can use the Glxinfo command card 3D Hardware graphics acceleration is available. For example, the output on the Radeon graphics card Glxinfo contains the following:

OpenGL renderer String:gallium 0.4 on AMD CEDAR

This shows the OpenGL 3d acceleration using the AMD Cedar Core graphics card, which should be the word "VMware on llvmpipe" If hardware acceleration is not available.

The open source OpenGL implementation is mesa,mesa up to the OpenGL interface, the lower layer through the hardware of Mesa Drive and hardware interaction. GLX is an extension of the X protocol for the interaction of OpenGL and X (GLX specification). The Mesa source package contains a large number of OpenGL sample programs, including sample code in OpenGL Red Book, code to invoke glut or GLX interfaces, code to invoke EGL, and so on.

Figure 1

Figure 1 shows the process of a 3D application running, the OpenGL drawing program commands are translated into the command buffer by the MESA driver of the user space, and other such as vertex information/texture information/index information is put into the corresponding buffer, Mesa driver saves the current drawing state for each application, when a 3D program switch occurs, the current state is saved and the next time the program is scheduled to run, the program's drawing state is restored to the hardware, and then the commands in the command cache are resumed. When a user space call sends a command to the kernel, the kernel driver programs the hardware from the command buffer of the program to start execution. This process is implemented under the DRI framework, where all the drawing processes do not request X,opengl to send commands directly to the hardware. GLX will not interact with X when initializing the window, requesting buffer and switching buffer.

Figure 1 from the literature "Graphic Engine Resource Management", this article describes some of the improvements made to earlier kernel DRM drivers, in this master thesis "A Fair-share Scheduler for the Graphics Processing Unit" has a clearer picture of some of the problems.

Graphics system for "original" Linux environments and AMD graphics driver programming (2) Introduction to--framebuffer, DRM, Exa, and Mesa