Testing Out AMD's DRI2 Driver Stack

Written by Wil Reichert in Display Drivers on 13 May 2009. Page 1 of 5. 37 Comments

For as long as I can recall, ATI/AMD video cards have typically had decent support in Linux. It's not hard to pick out points in time where drivers were slow to come (R300 sticks out in my mind), but that was not due to the lack of effort by the open-source community as it was the difficulty reverse engineering a chip with no documentation. Intel seems to be the one getting most of the press these days regarding their open-source graphics support, but AMD is putting forth its own notable effort as well. They have multiple full time employees working on open-source support and have released specifications and programming documentation for their entire range of chips. The past few months have seen a flurry of activity in graphics related development, and a fair amount of this is centered around AMD hardware.

Anyone who has read Phoronix at all within the last year will have noticed several graphics related acronyms constantly popping up such as DRM, DRI, Mesa, and Direct Rendering. More recently, things like KMS, GEM, DRI2, and Gallium3D have become ever more prevalent. These are all elements of the software stack that makes video hardware work in Linux. This software is contained in the kernel as well as across several different libraries and drivers. Specifically they are:

The Kernel - provides low-level access to the hardware
libdrm - user-space component that provides hardware acceleration via the kernel
Mesa - 3D rendering library
X Driver - Provides accelerated 2D and video

You see the question posed on mailing lists and forums all the time 'is card XYZ supported?' It is usually not a straightforward answer. Firstly - any card in recent history will run with the vesa X driver, so by default the answer is yes. Granted you get no accelerated 2D or 3D and performance will be reminiscent of that 486 you still have in your garage. You may also end up mode-setting to a lower resolution than your panel's native mode. Secondly - Due to the fact that the X driver and mesa are completely separate pieces of software, it quite possible to have accelerated 2D performance but no accelerated 3D. This is the current state of the R600-R700 cards, 3D support will hopefully be coming in the near future. Thirdly - usually what people mean by this question is will Quake/Doom/whatever run, i.e. is 3D working. Assuming proper support is in place at every level for your specific hardware then your games will be blazing fast, otherwise you will be looking at a CPU rendered slideshow.

As the new generations of graphics technologies are put into place, the four components that make up the stack will remain the same but their functions will change dramatically. Currently libdrm and the kernel communicate via DRI, which will change to DRI2. Mode-setting capabilities, which are currently in the X drivers, are being shifted to the kernel, hence called KMS, for kernel mode-setting. The memory management, which is also currently done in the X driver, will also be moved to the kernel, this is referred to as either GEM or TTM, depending on the implementation. Gallium brings a complete architectural overhaul to how Mesa handles different technologies and hardware and new features.

There has been a lot of hype around the latest technologies currently under development. This unfortunately creates the misconception that by being the first person on your block to compile everything together the performance of your beloved video card will adapt new magical capabilities and its performance will skyrocket towards the stars. Yes, these technologies are the future. Yes, they will eventually allow you to make the most of your existing hardware. Yes, your friends might be impressed, but probably not. No, it is not faster right now. No, its not feature complete yet. No, it is probably not even going to work on your hardware right now. It is all a work in progress and highly alpha. Development progressing a very rapid state, but there is still a lot of work to be done. Do not expect any miracles. I have seen it stated repeatedly that this approach is more for proper function than performance.

I am going to be comparing three graphics configurations. As a baseline, I will look at the latest released versions of everything. This will be representative of what most vendors are shipping in their latest distributions. For a look at what is just around the corner, I will be grabbing the latest code from the master branches of the various Git repositories. Finally as a preview of the upcoming graphics stack, I will be grabbing the latest code from select Git repositories.

All tests were run on an IBM ThinkPad T60. Its video card is an R500 class M10. The ThinkPad T60 also has an Intel Core Duo T2500, 3GB of RAM, and a 100GB FUJITSU MHV2100BH and 80GB Seagate ST980811AS hard drive. The installed OS is an up to date ~x86 install of Gentoo using GCC 4.4.0. The xorg.conf ATI driver options that were set include using the EXA AccelMethod, enabling BackingStore, enabling EnablePageFlip, and enabling DynamicClocks.

All tests were run with Phoronix Test Suite v1.8.0 from Portage. For the dri1-rel tests, the latest releases of the following were used - Linux 2.6.29, libdrm 2.4.9, and, Mesa 7.4.1, and xf86-video-ati 6.12.2. For dri1-dev I attempted to use the latest pull from the associated master branch of each repository. Unfortunately, the mesa master branch was not being cooperative at the time I was benchmarking, so I had to revert it back to 7.4.1 in order for any of the 2D benchmarks to complete without the system locking. For the DRI2 benchmarks I used various Git branches based off the work Jerome Glisse has done.

Related Articles