question about the /drivers/gpu/drm/radeon/ and xf86-video-ati-7.1.0

[sourcecodereader]

I want to understand how the open-source radeon drivers work under linux. Unfortunately, there is not much documentation about them. So, I resorted to reading the source code.

I managed to locate two different chunks of radeon-related source code:

1) The code under the directory /drivers/gpu/drm/radeon/ in linux source tree.
2) The source code in xf86-video-ati-7.1.0, downloadable from internet.

My question is: what is the relation and the difference between these two different sources? Which one is lower level? Which one calls the other?

[bridgman]

The radeon graphics stack includes a number of components. The first link is the kernel driver, while the second is the X driver. I'm not 100% sure, but I believe the X driver still talks to the kernel driver via "libdrm", which is basically the userspace interface to the kernel driver :

http://cgit.freedesktop.org/mesa/drm/tree/radeon

You also need the Gallium3D drivers in mesa (basically the hardware layer for the 3D or GL driver) :

http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium

drivers/r300, drivers/r600 and drivers/radeonsi are the "pipe" drivers aka the HW drivers for the graphics pipeline. r300 covers 3xx-5xx, r600 covers 6xx through NI, while radeonsi covers SI and above.

winsys/radeon is the "OS interface" or "windowing system interface", ie the interface for things like memory management and command submission. It talks to the kernel driver. Note that winsys code could potentially go through libdrm (see above) to get to the kernel driver but my understanding is that it contains some newer code than libdrm and goes directly to the kernel driver.

So... something like :

2D path : ati X driver => radeon libdrm => radeon kernel driver

3D direct rendering path : GL driver common (in mesa/mesa) => r600 (for example) pipe driver => radeon winsys => radeon kernel driver

(indirect rendering would work the same way except the application talks to the GL driver via the X protocol and X server rather than having the application call the GL driver directly)

[sourcecodereader]

not exactly what I was looking for.

The info was great, but not exactly what I was looking for. I'd rather liked to know what was the difference between

--the code located in the files located in xf86-video-ati-7.1.0
and
--the code located in the linux source directory drivers/gpu/drm/radeon

My guess is that the real drm driver is in drivers/gpu/drm/radeon, and xf86-video-ati-7.1.0 is for 2D acceleration only. But the code in xf86-video-ati-7.1.0 is so sparsely commented that there is no way to know what it does..

I think my best tack is to just read drivers/gpu/drm/radeon.

[przemoli]

The info was great, but not exactly what I was looking for. I'd rather liked to know what was the difference between

--the code located in the files located in xf86-video-ati-7.1.0
and
--the code located in the linux source directory drivers/gpu/drm/radeon

My guess is that the real drm driver is in drivers/gpu/drm/radeon, and xf86-video-ati-7.1.0 is for 2D acceleration only. But the code in xf86-video-ati-7.1.0 is so sparsely commented that there is no way to know what it does..

I think my best tack is to just read drivers/gpu/drm/radeon.

xf86-video-ati ==> ati X driver from Bridgman explanation.

And it do what ever X.org need from GPU. X.org talk with actual GPU only by xf86-video-ati (it can also talk by xf86-vesa but its very old mode and very limited, still there for cases when nothing else do not work).
Buffers management, painting on screen, displaying video, anything else X.org do will int the end go via xf86-video-ati. Which can accelerate it on GPU, or can do all operations on CPU and then only send bitmaps ready to display on the screen to the GPU.

[bridgman]

The info was great, but not exactly what I was looking for. I'd rather liked to know what was the difference between

--the code located in the files located in xf86-video-ati-7.1.0
and
--the code located in the linux source directory drivers/gpu/drm/radeon

OK, let's see. The code in xf86-video-ati is the X driver, while the code in drivers/gpu/drm/radeon is the kernel driver. I'll use those terms rather than folder names because they are shorter

Originally a "drm" (Direct Rendering Manager) kernel driver mostly handled submission of command buffers to the GPU hardware and coordinating access to the hardware when more than one process was using it. The kernel driver in drm/radeon does that plus modesetting (programming the display hardware on the GPU) and graphics memory management.

As przemoli said, the X driver (also called DDX or Device Dependent X driver) is what the X server calls into for modesetting and drawing operations, and the X driver then calls into the kernel driver when hardware access is required. Note that the X driver never actually calls into the kernel driver directly -- it calls libdrm (see link in earlier email) which is also userspace code, then libdrm performs the ioctl functions which actually enter the kernel driver.

Modesetting used to be performed in the X driver (requiring userspace access to GPU hardware) but these days the modesetting requests are passed down to the KMS code in the kernel driver and performed there. Same for memory management. For drawing functions the X driver prepares command buffers for the GPU and passes them to the kernel driver for submission to the hardware.

Note that the mesa code I mentioned in the earlier post (which you aren't asking about yet) actually does most of the drawing work these days, since toolkits and browsers increasingly use the OpenGL API for drawing rather than the X drawing operations. Even if the application uses indirect rendering (asking the X server to perform GL operations) the actual drawing is done by the mesa common code and the hardware drivers in src/gallium/...

[bridgman]

Something like this :



Note the drawing is simplified a bit, particularly on the mesa/pipe/winsys side.

The core "open source radeon drivers" include the X driver, libdrm code, the kernel driver, pipe and winsys drivers, along with additional code for things like OpenCL and UVD acceleration support.

[sourcecodereader]

Thanks

Thanks a lot to everyone who replied. Things are a bit more understandable now, especially after bridgman's diagram.

If I manage to understand the source, I plan to write an exposition of linux graphics stack.