If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Now that most of the rearchitecture work has finished the stack is getting pretty simple :

- kernel driver (aka drm) initializes the GPU, manages memory, and sets up the display. Having the kernel driver handle display setup is relatively new, and is referred to as Kernel ModeSetting (KMS)

- X driver (aka xf86-video-ati) hooks into the X server, passes display changes from the X server down to the kernel driver, and turns acceleration commands from the X server into GPU commands which are passed to the chip via the kernel driver

There are two types of Mesa HW drivers -- "classic" and Gallium3D -- and the transition from one to t'other is maybe half completed. Gallium3D drivers have the advantage of being able to support more than just 3D operations - things like OpenVG, OpenCL, 2D and video acceleration. Mesa is used for OpenGL in both cases, ie it's not "Mesa vs Gallium" it's "Mesa with classic HW drivers vs Mesa with Gallium3D HW drivers".

Older GPUs (r1xx, r2xx) will probably only ever use the classic drivers. More recent GPUs (r3xx-r5xx) are currently using a classic driver but a new Gallium3D driver is getting close to being able to replace the classic driver. The newest GPUs (6xx and higher) use a classic driver and work is just beginning on a Gallium3D driver.

You are right, I have an ATI 5850, the fglx drivers are really slow even scrolling web pages in firefox.... and the open source drivers are always "coming".... For me, the solution I've found is to execute Linux in a Virtualbox machine inside Windows 7. No more problem with graphics, suspend / hibernate, I can make a backup of the whole system, and I dont have to reboot to play some games.

i think bridgman isn't a human i think he is a openCL based KI runs on a R900!

the secret plan is to fire all humans out and let the work be done by R900 chips!

bridgman is just the first prototype of a really smart KI based on R900!

I think its very good of AMD to hang out on these forums, it really shows that they care about what customers and community think.

I'm not expert on linux, but i've compiled my own kernels and been playing with systems for about 4 years. Still the way that these graphics drivers work seems to be so incredibly complicated. (also i'm a theoretical chemist by trade not a programmer)

I really would like to see someone come up with some good documentation, maybe a flow chart or two, to help people understand the development process.

@bridgman
Thank you very much - that realy helped me to understand how it works. :-)
I think i will start over with trying some OpenGl coding as soon as possible :-)

+1. Great explanation, thanks!

Quick further question:
The "GPU commands" - are these a stream of binary data which passes between the HW driver and the DRM, with the DRM forwarding it to the actual hardware? If so, how does it handle the case when both the X driver and the mesa HW driver wants to talk to the card simultaneously?

Do the X drivers and the mesa HW drivers speak the same "language" to the DRM, meaning it does some kind of shared-bus arbitration type thing? Or do they both have separate interfaces to the DRM?

I think this is the major bit of the puzzle still for me.

Ah, ANOTHER quick question:
Given that we hear about X-type state trackers for gallium3d, does this mean that in the end the dedicated X driver as we know it will be phased out? It *sounds* like when gallium3d and all its various state trackers is/are complete, it will be able to handle every kind of graphics API out there, convert it into these low-level GPU commands, and thus get it rendered (presumably in a thoroughly accelerated manner). Is that the case?

Quick further question:
The "GPU commands" - are these a stream of binary data which passes between the HW driver and the DRM, with the DRM forwarding it to the actual hardware? If so, how does it handle the case when both the X driver and the mesa HW driver wants to talk to the card simultaneously?

Afaik this happens by that DRM mostly consisting of KMS and X driver and Mesa driver are both KMS clients. As to exactly how KMS architecture works, there might be more information about that somewhere but in a nutshell KMS allows multiple clients to use the card at the same time and handles memory and other stuff in such a way that clients won't end up eg getting each other's data.