The future of AMD/ATI drivers

[dptkby]

I'm sorry if this has been answered lots of times before, but there's really a lot going on with different ATI/AMD drivers and some of the information gets outdated really quickly so I'm just gonna ask you here:

I recently bought a HD 4850 and when looking up Linux drivers for it I got the impression that the radeonhd driver was the future of AMD/ATI on Linux, among other things, it seemed to be at least semi-supported by AMD. Now I understand features are ported back and forth between all drivers and also, there's talk about Gallium3D and it making all these drivers obsolete in the future (can stuff from the open drivers be used when developing whatever it is that makes Gallium3D support AMD/ATI?). So, what are your views on the future of AMD/ATI drivers under Linux?

Also; I use Arch Linux (64-bit) and a HD 4850 (R7**, I think). Now, I guess if I want gaming, Catalyst is really the only option, and I'll probably try it just to get the HoN beta running. But when gaming is not a concern, what is the driver that works best today?

I'm guessing watching HD videos might be an issue with some of them, and of course we all want snappy 2D performance. And what about Compiz, does that bring us right back to Catalyst?

Thank you!

[suokko]

I recently bought a HD 4850 and when looking up Linux drivers for it I got the impression that the radeonhd driver was the future of AMD/ATI on Linux, among other things, it seemed to be at least semi-supported by AMD. Now I understand features are ported back and forth between all drivers and also, there's talk about Gallium3D and it making all these drivers obsolete in the future (can stuff from the open drivers be used when developing whatever it is that makes Gallium3D support AMD/ATI?). So, what are your views on the future of AMD/ATI drivers under Linux?

Galliom 3D is just a internal api to make GPU driver writing easier for mesa. So of course new open source driver will be able to use code from the old architecture but question is how much it should? After writing the old driver devs have learned a lot about hardware and now there is better skill level to write better driver.

Also; I use Arch Linux (64-bit) and a HD 4850 (R7**, I think). Now, I guess if I want gaming, Catalyst is really the only option, and I'll probably try it just to get the HoN beta running. But when gaming is not a concern, what is the driver that works best today?

Radeon (xf86-video-ati) and RadeonHD should work equally well. There maybe some bugs in one of them that is not present in another. But if you need fglrx then you shouldn't mix oss drivers in same system. Switching between drivers isn't simple. (You could make dual boot system. One with all the latest bits and OSS driver while another linux installation with 2.6.28- kernel and xserver 1.5 to get stable fglrx)

I'm guessing watching HD videos might be an issue with some of them, and of course we all want snappy 2D performance. And what about Compiz, does that bring us right back to Catalyst?

You can use kwin composite with OSS drivers if yo uset it to use RENDER. Also there is metacity composite for gnome but it doesn't provide so much eye candy.

But for compiz you need fglrx or wait for mesa 7.6.

[bridgman]

The main thing to remember is that there are three different drivers in a modern graphics stack; the X driver (radeon/radeonhd), the kernel driver (drm), and the 3D driver (mesa). The fglrx (Catalyst) proprietary driver stack includes all three.

The X drivers currently include both modesetting (display setup) and 2D/video acceleration code. The modesetting functions are being added to the kernel driver (Kernel Modesetting or KMS) and KMS is expected to replace the "userspace" modesetting code in the X drivers over time.

Gallium3D is a new internal API for the 3D driver (mesa) which was designed to also be useable by other drivers. One proposed application for Gallium3D is replacing the hardware-specific acceleration code in the X driver with hardware-independent calls to Gallium3D (which *would* still include hardware-specific acceleraction code), allowing the use of a generic X driver in place of radeon / radeonhd.

KMS has already started to appear in bleeding edge distros (just Fedora so far AFAIK) but Gallium3d-based acceleration in the X drivers is still at a prototype stage for now AFAIK.

What may happen in between those two steps is the use of Gallium3D APIs to accelerate more of the video playback path, specifically some or all of what is called "decode acceleration", building on top of the current Xv capabilities, which are often referred to as "render acceleration".

[dptkby]

Thanks for the info! And no, I wasn't going to try to use both fglrx and open drivers at the same time, just try how well fglrx does the 3D thing for me and then use open drivers.

The main thing to remember is that there are three different drivers in a modern graphics stack; the X driver (radeon/radeonhd), the kernel driver (drm), and the 3D driver (mesa). The fglrx (Catalyst) proprietary driver stack includes all three.

Just a question: obviously the X driver (radeonhd/radeon) includes hardware-specific code (though in the future, it might not have to?). If I understood your post correctly, mesa (later using Gallium3D API) needs hardware-specific code too. Probably drm too?

But say, for example, that I was laying awake at night just waiting for KMS support for my card. Where is this work being done? The same (kind of) goes for mesa and drm hardware-specific stuff. Is this totally separate from radeon/radeonhd? I'm just curious, it's possible that my questions don't make much sense as I really don't know much about this...

Thanks!

[bridgman]

Good question. If you go back a year, then the X driver (radeon/radeonhd), the kernel driver (drm), and the 3D driver (mesa) all have hardware-specific code. The X driver has code for modesetting and 2D acceleration, while the mesa driver has hardware-specific code for 3D acceleration inside the HW driver layer (src/mesa/drivers/dri/<pick a GPU>).

This is all happening in a bunch of steps, some of which have now been completed :

1. KMS implements modesetting code inside the drm. This also requires that a common memory manager (GEM/TTM) be implemented in the drm, and that KMS use GEM/TTM to allocate the frame buffer and any other buffers which the X or Mesa drivers will need to access. This task has been completed; KMS/GEM/TTM was merged into 2.6.31, using modified X and Mesa drivers in branches to demonstrate functionality. Note that this task allows the drm to operate in 2 modes; the old way where drm only starts up when initialized by the X driver, and the new way where drm starts up at boot and takes over control of the GPU immediately.

2. X and Mesa drivers are modified to work with KMS :

- add new modesetting paths to X driver which call drm for modesetting rather than hitting HW directly
- modify acceleration code in X driver to use GEM/TTM buffer management rather than managing memory locally

The acceleration changes were non-trivial since the old code assumed that buffers would "stay put" once allocated, but under GEM/TTM the buffers can move around and have to be locked down before each use and unlocked afterwards.

- modify Mesa driver to use GEM/TTM buffer management rather than managing memory locally
- modify Mesa driver to use DRI2 when using KMS/GEM/TTM

The radeon-rewrite effort included the last two tasks plus consolidation of R100/R200/R300 code. The 6xx-rewrite branch was where we modified the in-process 6xx/7xx mesa driver to be compatible with radeon-rewrite, at least for operation over a pre-KMS drm.

At this point both the X and Mesa drivers are capable of operating in two modes; with a pre-KMS drm they run "the old way" with each component doing some of its own memory management, and with KMS active they run "the new way" making use of the common GEM/TTM memory manager in drm. This task has been largely completed; Mesa and radeon changes were merged to master in June and July respectively.

**** this is roughly where the drivers are today, at least for 1xx-5xx GPUs, with 6xx-7xx WIP ****

3. Replace "classic" Mesa HW drivers with "Gallium3D" HW drivers. This work has started but is still in progress. The Mesa code has been modified (by TG) to be able to use new Gallium3D drivers or the "classic" Mesa HW drivers. Gallium drivers are located in a different part of the tree (src/gallium/drivers/<pick GPU>) from the classic HW drivers (src/mesa/drivers/dri/<pick GPU>). The current Gallium3D framework implementation requires DRI2, so this step can't really happen until the previous one is largely completed.

4a. Once Gallium3D drivers are working and being used in Mesa, start using them for acceleration in the X driver as well. This involves writing some new acceleration code paths in the X driver which call into Gallium3D to use the GPU hardware rather than having hardware-specific code. This last part is at the "seems like it should work, but we don't know how well it will work" stage AFAIK.

4b. Once Gallium3D drivers are working and being used in Mesa, start using them for video codec acceleration as well.

**** this is roughly where the drivers should be in a year or so, possibly sooner ****

Does that help, or did I make things worse ? I guess this would have been a great blog post TWO YEARS AGO

[d2kx]

Haha bridgman did it again. I can't count how many times he wrote great, long posts about what is going on and what the things actually do.

Thanks again, really appreciate it!

[mespina]

omg nice i wnt one xD

[Yomp!!]

I'm no expert on Open Source drivers or the Open Source ATI drivers (just starting to get my feet wet), but from what I've been able to gather, its all about Gallium 3D, KMS and DRI 2 and all that stuff just like what Bridgman said in his very enlightening and informative post.

I would say the future looks bright, however I can only say this as a user testing out RadeonHD on a 3200 IGP on a 780G motherboard. The 2d is extremely fast using EXA, much faster than that of my 9600 GT using the nVidia proprietary driver.

You might have decent luck with the proprietary fglrx driver for 3d at this point in time, however that also depends on what kernel you're using. But don't be surprised if things don't work according to plan, even if you are using a compatible kernel.

I look forward to the future

[highlandsun]

Sadly, in all of that very well written and informative post, not a single peep about video codec acceleration. Are there really more people using computers out there who care about 3D games than there are just trying to watch a movie on their "HD-compatible" machines?

[rbmorse]

There are more people _here_ that care about 3D games and there are just trying to watch a movie on their "HD-compatible" machines.