Testing Out AMD's DRI2 Driver Stack

[phoronix]

Phoronix: Testing Out AMD's DRI2 Driver Stack

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.

http://www.phoronix.com/vr.php?view=13825

[ivanovic]

Nice article, thanks for writing it. This way some users might see that this is still "work in progress" and that they should not expect too much when switching right now.

[aaaantoine]

Hoo... The transition will certainly be a hairy one.

[curaga]

Nice to see an actual boost already in one area (Urban terror)

[GreatWalrus]

Great article Michael. I like how you interpreted it as more of a "work in progress" rather than bashing its current regressions. I think a follow-up article on a new release would be awesome! (maybe you could use the same graphs as in this article to compare this dri2 version).

[egon2003]

It is exciting to watch all this unfold and I would say in another six to eight months you can expect some remarkable things.

Considering the company involved and its previous history with linux software I seriously doubt that. But I will be happy if I am wrong.

[adyroman]

I'm sorry, I have to take issue to the first phrase in the article:

"For as long as I can recall, ATI/AMD video cards have typically had decent support in Linux."

Are you serious? Just a few years ago ATI cards were a _huge_ no-no for anybody wanting to use linux. 2D performance with the fglrx driver was complete crap IIRC; I had a Radeon 9500 (non-Pro) that was almost unusable in Linux due to the poor performance of the fglrx driver (and radeon had no 3D support, not to mention that 2D performance wasn't much better either). Let's face it, both Intel and Nvidia have far better places in the linux support category, even though Intel produces low 3D performance graphics cards.

What does decent linux support mean? That they did have some crappy drivers out there? That's not decent IMHO.

[bridgman]

I'm sorry, I have to take issue to the first phrase in the article:

Maybe the author was talking about the open source drivers.

[bugmenot]

Very nice! Nice also to see an article that is not from michael (not that those are bad), too.

I'd like to see such benchmarks every few months when there was a change in the code that could cause more speed.

I also use DRI2 and KMS and it works quite okay. :)

[Melcar]

Maybe the author was talking about the open source drivers.


Even the binaries were "usable". I remember running my old 9800 and 9600 cards on the old drivers; performance was lacking, but they got the job done. I honestly could never understand what all the fuss was about with ATI drivers even back then.

[crumja]

One nice thing to see would be the same results for fglrx (or at least the fglrx results with the last working kernel/xorg that supports the hardware). This would give the community a baseline for where we are now and how much more we have to do.

Otherwise, all we have to go on is bridgman's pronouncement of 3D performance in the 70% range of current fglrx.

[Ant P.]

Great article Michael. I like how you interpreted it as more of a "work in progress" rather than bashing its current regressions.

I hate to burst your bubble, but that's only because he didn't write this article...

[bridgman]

Otherwise, all we have to go on is bridgman's pronouncement of 3D performance in the 70% range of current fglrx.

"Prognostication" is probably more accurate than "Pronouncement" :D

The "60-70%" number was an *estimate* about how far the development community is likely to take the drivers over time, based on discussions with community and in-house driver developers. The number is an average, so some apps will be faster and others slower, and is based on two things :

- estimates of the effort required to achieve increasing levels of performance
- estimates of the point where developers will decide to spend their time working on other areas of the graphics stack instead of improving 3D gaming

Again, this is not an estimate of what is POSSIBLE, just what is LIKELY.

[cruiseoveride]

For as long as I can recall, ATI/AMD video cards have typically had decent support in Linux.
Correction.
For as long as I can recall, ATI/AMD video cards have typically had very broken support in Linux.

[MostAwesomeDude]

This is easily the most accurate article I've read in a while.

I'd just like to reaffirm the assertion that Mesa 7.5 will include Gallium Radeon code, and that that code is highly experimental and generally not useful for anything.

[Melcar]

One nice thing to see would be the same results for fglrx (or at least the fglrx results with the last working kernel/xorg that supports the hardware). This would give the community a baseline for where we are now and how much more we have to do.

Otherwise, all we have to go on is bridgman's pronouncement of 3D performance in the 70% range of current fglrx.


From my own testing it's more like 20-50%. I can't wait to get my hands on a finalized Gallium3D driver and bench it against fglrx.

[drag]

From my own testing it's more like 20-50%. I can't wait to get my hands on a finalized Gallium3D driver and bench it against fglrx.

"finalized" is a odd term to use. Development of the drivers will stop right around the time people stop using them..

(that is one of the nice things about OSS drivers is that as long as people are using them then they'll be supported. My oldest laptop uses a ancient ATI mobility chipset that had it's supporte dropped years and years ago by the flglx drivers, but the OSS stuff works decently and is still gettting occasional bug fixes.

But I would not expect any massive improvements in benchmarks from Gallium. Any performance improvements will be a slow small build up of performance over time.

-------------

the thing I am hoping most from Gallium right now is consistency.

OSS drivers are plagued by inconstanty reliability, performance, and API support. This means that for games and applications that take advantage of Linux have to put a lot of effort into driver-specific behavior and fixes to support a wide veriaty of users.

Most projects don't have the resources and just concentrate on Nvidia first and then Flglx a second, if that. The OSS video drivers may get a few bug work-arounds in applications, but that is few and far between.

So for users using OSS drivers they not only have to deal with confusing and oddball behavior they are likely to run into problems when trying to play games or do other things related to GPU acceleration.

For example say your using Mythtv... the XvMC acceleration stuff is very spotty.. for the Intel driver you have very different setup for getting XvMC on the older 810-style devices vs the newer 9xx GMA devices and XvMC is not really that useful for accelerating lots of different things other then mpeg-2. So that makes a user go 'low-level' and edit Xorg to enable it or get a *.so file or something like that and edit a couple files to get it enabled. And even after they put that effort into it it's not something that is enabled by default, so it's not widely used, so it's not widely tested, and it's not really good at helping to accelerate HD video (which is usually going to be H.264 for most people) which is going to be people's primary interest in accelerating. (a decent Pentium 4 can play a DVD-resolution-sized video with doing raw unaccelerated x11 and software scaling.. but even my dual cores choke on 1080p HD stuff.)

This leads to bad usability and a reputation that Linux is buggy and hard to use. People who do not necessarially care about having the best performance are still forced to install propretiary drivers due to compatibility reasons and this, again, is not really easy to do and leads to bad user experiences, unproductive platform, and bad reputations.

Sooo....

Gallium is nice because its design tries to minimize, or at least isolate, the hardware-specific code in the driver/API stack. With the current model while the DRI and the DDX drivers are all based on the same sort of design and same code bases.. they are all very unique and have hardware specific features spread all over the place. With Gallium they try to isolate that so that you get a much more simplified OpenGL or EXA implimentation that then connects using standardized methods to the hardware-specific code.

What this gets you is that the APIs are going to be much more unified between drivers and application compatibility should improve quite a bit, if not performance. And then since the hardware-specific code is isolated then that makes it a much easier design to deal with for driver developers and then they can get better hardware support done faster.

..........


I figure once they get to the point were browsers will stop locking up X Windows, 3D games and applications stop having ugly artifacts and crashing all the time, suspend and video modesetting is very reliable... then that is when they'll start putting effort into optimizing performance.

[xeros]

It's impressive how fast and good the work is done.
Thanks for good benchmarks.
Could you do some more benchmarks of 3D games (for example Nexuiz and OpenArena) which could be run on DRI2 already and maybe compiz/kde window effects performance?

[Melcar]

I meant finalized in terms of "usable by end-users".
As for Gallium, I won't bitch and moan for performance. Stability and feature support are my main concerns. 30-60% of the 3D performance of fglrx is fine with me. Getting applications to run in a stable manner is more important to me than squeezing extra frames. Optimization can come latter.

[mendieta]

Folks, a bit off-topic, but I still can't have 3D accel in my AMD/ATI Radeon HD 3200 IG in Kubuntu 9.04 ... anyone knows what happened with the Catalyst 9.5 release? It was rumored to be out today (just google for Catalyst 9.5)

Thanks!

[MostAwesomeDude]

But I would not expect any massive improvements in benchmarks from Gallium. Any performance improvements will be a slow small build up of performance over time.

Actually, it tends to go in spurts and bursts, especially with my coding style. :3

[Pitabred]

<snip>
(a decent Pentium 4 can play a DVD-resolution-sized video with doing raw unaccelerated x11 and software scaling.. but even my dual cores choke on 1080p HD stuff.)
<snip>


I think I've stated it elsewhere, but on the mplayerhq.hu (http://www.mplayerhq.hu/design7/news.html) homepage they give you instructions on how to compile the mplayer-mt. It lets me play 1080p on an Athlon X2 4600+ CPU with Xv. While it's not GPU acceleration, it's a heck of a lot better than nothing. My MythTV system with an HD3200 is awesome with the open source drivers. The only thing that could make it better is if I could start doing some 3D gaming on it as well.

[paul_one]

I think the "ATI/AMD" remark at the start of the article was directed at the post-buyout company - not the pure "ATi" drivers.

I used to have a 9800 Pro, was VERY disappointed that the Linux drivers sucked so badly (and the installer back then was hell).

With Nvidia I've had fine binary drivers - although I wish they'd grow up and help out the Noauvouvouioviuoi project with hardware docs at least (ermm, what part of the hardware command structure is DRM'd then Nvidia?).

But, anyhoo, VERY nice article.
Correct performance stats (nice for a change), wasn't condeming of the performance, and explained the various aspects of KMS/DRI/gallium/etc very well.

Phoronix, give this guy more stuff to write about!!

[Yfrwlf]

What this gets you is that the APIs are going to be much more unified between drivers and application compatibility should improve quite a bit, if not performance.

Which means you will get better performance, because as you unify things, testing is easier and improvements effect more hardware, etc. Unifying/standardizing more means more focus on goodies like performance and such, and less time wasted, which will yield a better Linux experience. Can't wait. :D

[highlandsun]

Can anyone point me to some articles/discussions for background on TTM/GEM/KMS? This whole development direction seems to me to be contrary to good design principles - there are more moving parts, and putting more into the kernel means more context switches required to get any useful work done. Back when I worked on X (I wrote the X11R1 port for Apollo DOMAIN/OS) we would have had our heads chewed off for trying to push any of this work into the kernel...

[bridgman]

Most of the real discussion was a few years ago, but the key point is that there were some real serious problems with the current architecture (possibly worse than the ones you were dealing with) which had to be addressed.

The main problems were :

- multiple graphics drivers, some in user space, and some in the kernel, over-writing each others settings during common use cases

- inability to share memory between 2D and 3D drivers, which made any kind of desktop composition inefficient and slow

Both the 2D and 3D drivers need context switches in order to access the hardware anyways, since the direct rendering architecture uses drm to arbitrate between the ddx and mesa drivers, and to manage the shared DMA buffers (aka ring buffer) used to feed commands and data into the graphics processors. I don't think these changes really introduce more context switches as much as change the dividing line between user and kernel responsibilities.

I'm a bit rusty on the history (my hands-on X experience was before X11), but my understanding is that user modesetting is a relatively new addition to X, and that the KMS initiative is arguably going back to the way modesetting was handled in earlier versions of X which were presumably built on existing kernel drivers. I haven't had much luck finding online references to support this, but I have been told this by a number of people who have worked on X for a very long time.

If you're saying that the DRI architecture is fundamentally flawed and that all graphics should go through a single userspace stack (presumably in the X server) then that's a different discussion of course.

Jesse Barnes wrote a good summary of the rationale for moving modesetting into the kernel, and there is a good discussion (plus the odd rant ;)) in the subsequent comments : http://kerneltrap.org/node/8242

Thomas's original TTM proposal is a pretty good summary of the goals related to memory management : http://www.tungstengraphics.com/mm.pdf

[sc3252]

Even the binaries were "usable". I remember running my old 9800 and 9600 cards on the old drivers; performance was lacking, but they got the job done. I honestly could never understand what all the fuss was about with ATI drivers even back then.

Well, I too used a 9800 np and it was to say the least unstable. I would get driver crashes by just by hitting Ctrl+AlT+F1 or any other f key. Also there were quite a few times when video applications would give me a black screen. Not including all that the community usually had to patch the drivers themselves because a lot of the time they would not compile. They also had issues with VIA motherboards, so the drivers wouldn't even load without some secret patch(seriously I had to look for 3-5 hours before I could find a patch to my motherboard kt333).

[cliff]

I would have to disagree with the author.
I have had a lot of problems with my ATI card on Linux.
In fact it has caused me many system re-installs.
I have the 4870 X 2 and no 3d support on Jaunty Jackalope. I tried installing the Catalyst 9.4 and when I reboot my machine it locks up and the colors are all messed up. I wish I would have bought a Nvidia card. I used to use windows and the Vista drivers were not much better.

[highlandsun]

Most of the real discussion was a few years ago, but the key point is that there were some real serious problems with the current architecture (possibly worse than the ones you were dealing with) which had to be addressed.

The main problems were :

- multiple graphics drivers, some in user space, and some in the kernel, over-writing each others settings during common use cases

- inability to share memory between 2D and 3D drivers, which made any kind of desktop composition inefficient and slow

Both the 2D and 3D drivers need context switches in order to access the hardware anyways, since the direct rendering architecture uses drm to arbitrate between the ddx and mesa drivers, and to manage the shared DMA buffers (aka ring buffer) used to feed commands and data into the graphics processors. I don't think these changes really introduce more context switches as much as change the dividing line between user and kernel responsibilities.

I'm a bit rusty on the history (my hands-on X experience was before X11), but my understanding is that user modesetting is a relatively new addition to X, and that the KMS initiative is arguably going back to the way modesetting was handled in earlier versions of X which were presumably built on existing kernel drivers. I haven't had much luck finding online references to support this, but I have been told this by a number of people who have worked on X for a very long time.

If you're saying that the DRI architecture is fundamentally flawed and that all graphics should go through a single userspace stack (presumably in the X server) then that's a different discussion of course.

Jesse Barnes wrote a good summary of the rationale for moving modesetting into the kernel, and there is a good discussion (plus the odd rant ;)) in the subsequent comments : http://kerneltrap.org/node/8242

Thomas's original TTM proposal is a pretty good summary of the goals related to memory management : http://www.tungstengraphics.com/mm.pdf

Thanks, those references were pretty interesting.

Yeah, I guess a lot of things were simpler on the Apollo workstations; they had no hardware text mode, they really only had one supported graphics mode per given machine configuration. The one wrinkle is that they already had their own native graphics/windowing system that was not related to X. There were two porting efforts going on, one to simply layer the X APIs on top of the native APIs, and one to drive the hardware directly. I think ultimately we had to accept the overhead and just layered on top of the Apollo APIs, to allow native apps to continue to run alongside X apps. Otherwise we would have had the same issues - multiple drivers talking to the same graphics hardware...

As for DRI ... we obviously wouldn't need to fret over "redirected direct-rendering" if everything was going through the X server...

[bridgman]

In fact it has caused me many system re-installs.
I have the 4870 X 2 and no 3d support on Jaunty Jackalope. I tried installing the Catalyst 9.4 and when I reboot my machine it locks up and the colors are all messed up.

A few people have reported problems with the X2 boards and Jaunty, although they didn't show up in our "early look" testing on server 1.6. Did you see the same problems with Intrepid ? If not, it might be worth staying on 8.10 until we finish QA testing & bug fixing on Jaunty, and announce support in the release notes.

[nanonyme]

with Xv. While it's not GPU accelerationErr, yes it is? Wikipedia: "Most modern video controllers provide the functions required for XVideo; the feature is known as hardware scaling and YUV acceleration or sometimes as 2D hardware acceleration. "
http://en.wikipedia.org/wiki/X_video_extension
Edit: Oh, right. You meant as in decoding acceleration. Well, nice to see modern CPU's can actually do it with full quality with multithreading, I had to downscale playback quite a bit on my AMD64 3500+ to get it to work fluently.

[cliff]

A few people have reported problems with the X2 boards and Jaunty, although they didn't show up in our "early look" testing on server 1.6. Did you see the same problems with Intrepid ? If not, it might be worth staying on 8.10 until we finish QA testing & bug fixing on Jaunty, and announce support in the release notes.

No, in Intrepid the Catalyst drivers were progressing nicely. But now with Jaunty they are a no-go. I though about going back to Intrepid but I have everything working nice in Jaunty except 3d so I am taking a break from gaming for now. Hopefully Catalyst 4.5 will soon fix the problem.

[nanonyme]

No, in Intrepid the Catalyst drivers were progressing nicely. But now with Jaunty they are a no-go. I though about going back to Intrepid but I have everything working nice in Jaunty except 3d so I am taking a break from gaming for now. Hopefully Catalyst 4.5 will soon fix the problem.4.5? o.O Did you mean 9.5?

[cliff]

4.5? o.O Did you mean 9.5?

Yes 9.5 thanks :)

[agd5f]

This patch fixes the Xv problems with Glisse' kms DDX:
http://www.botchco.com/alex/xorg/kms_fix_clipping.diff

[Veerappan]

This patch fixes the Xv problems with Glisse' kms DDX:
http://www.botchco.com/alex/xorg/kms_fix_clipping.diff

Hey Alex,

Thanks for the diff. I patched a fresh copy of the radeon-rewrite branch using what you just posted, and the Xv output is indeed improved, but there's still some cropping going on. I am seeing what looks like the upper-left quadrant of the video stream (using Miro to test using Xv output, M22 (x300 mobility), Ubuntu 9.04 w/ KMS/DRI2/etc), but the other 3/4 of the video are getting chopped off.

I'll probably play around with the offset changes you had in your diff to see if I can get it to work on my machine, but no guarantees.

--Aaron

[agd5f]

Hey Alex,

Thanks for the diff. I patched a fresh copy of the radeon-rewrite branch using what you just posted, and the Xv output is indeed improved, but there's still some cropping going on. I am seeing what looks like the upper-left quadrant of the video stream (using Miro to test using Xv output, M22 (x300 mobility), Ubuntu 9.04 w/ KMS/DRI2/etc), but the other 3/4 of the video are getting chopped off.

I'll probably play around with the offset changes you had in your diff to see if I can get it to work on my machine, but no guarantees.

--Aaron

you'll also need to revert:
8338385cd94b35f54b25cf2576890159f8dd9f71
or just apply this patch:
http://www.botchco.com/alex/xorg/kms_fix_xv.diff
which contains both the reversion and the clipping fix.

[Veerappan]

you'll also need to revert:
8338385cd94b35f54b25cf2576890159f8dd9f71
or just apply this patch:
http://www.botchco.com/alex/xorg/kms_fix_xv.diff
which contains both the reversion and the clipping fix.

Much better. The picture looks correct as far as I can tell. Xv is now usable, and much improved over having to set gstreamer to non-Xv output (was getting alternating smooth video and a slideshow watching videos earlier).

Thank you for the patch, and keep up the great work.

--Aaron