Radeon vs. RadeonHD Drivers In H1'08

[phoronix]

Phoronix: Radeon vs. RadeonHD Drivers In H1'08

For Linux distribution vendors, right now is proving to be an awkward time for them as they decide which ATI driver will ship as the default choice in their spring distribution refresh. The problem used to be whether to ship a binary-only driver in the distribution in order to provide "out of the box" support for all available graphics hardware, but on the ATI/AMD side the software distributors are now facing the challenge of which open-source driver they should call the de facto standard. In this article we are briefly looking at the matter of the xf86-video-ati vs. xf86-video-radeonhd drivers, the highly political issue of AtomBIOS, and what some of the popular Linux distributions are deciding to use this spring.

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

[LauriM]

On the NVIDIA side, distribution vendors may soon find themselves in a similar boat choosing between the official xf86-video-ati 2D driver and the reverse-engineered Nouveau driver, which will be capable of both open-source 2D and 3D support.
That should be the nv driver?

Still a nice article. Thank you. I enjoy following Radeon development with Phoronix articles.

[Michael]

That should be the nv driver?

Still a nice article. Thank you. I enjoy following Radeon development with Phoronix articles.


Oops, yeah. Fixed, thanks :)

[l8gravely]

Phoronix: Radeon vs. RadeonHD Drivers In H1'08

For Linux distribution vendors, right now is proving to be an awkward time for them as they decide which ATI driver will ship as the default choice in their spring distribution refresh. The problem used to be whether to ship a binary-only driver in the distribution in order to provide "out of the box" support for all available graphics hardware, but on the ATI/AMD side the software distributors are now facing the challenge of which open-source driver they should call the de facto standard. In this article we are briefly looking at the matter of the xf86-video-ati vs. xf86-video-radeonhd drivers, the highly political issue of AtomBIOS, and what some of the popular Linux distributions are deciding to use this spring.

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


Right now I'm using the RadeonHD driver from their GIT repository on my home machine, but I'm not sure I'm happy with it so far. This is a Hardy Heron box too, so I'm sure I'm just running into all the usual teething problems with Beta software.

I'm very willing to try both, and I'm actually looking to see if I can enable Compiz stuff on my X1600 Silent card.

The only complaint I have right now is that I think my old Matrox G450 had crisper text, and with my bad eyes, that's a big issue. Not sure yet, and I haven't had time to play. It could just be my font choices right now.

I'd love to see an article which tests both drivers on an R500 GPU to see how the performance and features compare.

John

[Melcar]

Yeah, a comparison is in order now. Maybe even compare them to fglrx in the near future.

[remm]

F9 now has independent packages for both Radeon HD and Nouveau. If they keep on as they did for F8, those two will be kept really closely aligned to the ongoing developments.

Although nv really sucks, I don't think nouveau will replace it right now, as it has bad G80 support.

[stan]

If you keep adding support to new cards in the same driver (radeon), it's going to make the driver slower even for the old cards due to the penalty of card-specific if statements. So it would be better from a performance p.o.v. to have a new driver like radeonhd. What's even more sad is that once someone indroduces support for r500/r600 into the radeon driver, no one will take the time to remove that support if it becomes superfluous, and were stuck with two drivers forever and a split tester base.

Also, AtomBIOS sounds like just an excuse for AMD to not provide documentation. Furthermore, if you have a bug in AtomBIOS, you can't fix it unless you re-flash the card which would be dangerous.

[remm]

Also, AtomBIOS sounds like just an excuse for AMD to not provide documentation. Furthermore, if you have a bug in AtomBIOS, you can't fix it unless you re-flash the card which would be dangerous.

It's the same problem as with the bad bioses on some old laptops with an i810 (you cannot use the display native resolution using the straight bios of the card). Really not a good situation to be in, so relying on the bios is a bad thing.

[bridgman]

If you keep adding support to new cards in the same driver (radeon), it's going to make the driver slower even for the old cards due to the penalty of card-specific if statements. So it would be better from a performance p.o.v. to have a new driver like radeonhd.

Here's the issue -- only the modesetting hardware changed between 4xx and 5xx. The acceleration hardware is largely unchanged, so the same code generally runs on both 3xx/4xx and 5xx parts.

Also, AtomBIOS sounds like just an excuse for AMD to not provide documentation.

Sure, but we already provided the documentation ;)

We are providing complete documentation for what the registers do, and in some cases are creating new docs which explain how the pieces fit together. What we were hoping not to have to provide is the "set this register to 0x7... set that register to 0x0015fe2" level of detail since that was already coded and heavily tested in AtomBIOS.

Furthermore, if you have a bug in AtomBIOS, you can't fix it unless you re-flash the card which would be dangerous.

One of the design criteria for AtomBIOS was the ability for the driver to over-ride any table with a newer version if required. We have been using AtomBIOS for the Windows drivers for a few years now and have never had to patch a table, but the mechanism is there.

It's the same problem as with the bad bioses on some old laptops with an i810 (you cannot use the display native resolution using the straight bios of the card). Really not a good situation to be in, so relying on the bios is a bad thing.

Actually, that's not the case with AtomBIOS. We don't restrict you to specific modes. There is a traditional VBE / BIOS layer running on top of AtomBIOS which does have a fixed mode table, but that only affects VBE calls.

[d2kx]

The ati/radeon devs are doing a great job, but in my opinion, RadeonHD is the way to go if you have R500+ hardware... at this early state I found RadeonHD to be rockstable already while ati/radeon has serious problems with TexturedVideo and 2D acceleration for me, and I think the RadeonHD driver will take the lead in performance and stability later this year...

Great article, and I have to say that Mandriva is doing the best in my opinion by using ati/radeon for R100-R400 (and Mandriva keeps their packages uptodate) and RadeonHD for R500+. I never liked Ubuntu and I don't think it is easy for the normal user if he has to compile his drivers by himself, because Ubuntu is already outdated before a new release arrives, and Ubuntu doesn't update their packages at all... Mandriva is overall very underrated and Ubuntu overrated...

Oh and I've noticed Michael using KDE with Mandriva :) Keep it up!

[sreyan]

For those in the know, will the AtomBios work with cards that have firmware for macs?

I have a 2600xt mac card that works perfectly well with the latest versions of RadeonHD.

I'd appreciate clarification on the difference between the firmware/bios in the mac cards and also if atom bios would/should/does support it.

Regards,
-Sreyan

[bridgman]

Yes, the same AtomBIOS calls are used by the Windows driver which runs on the Mac. I think you need to be running under BootCamp to expose the firmware today.

[bridgman]

while ati/radeon has serious problems with TexturedVideo and 2D acceleration for me

It's probably worth mentioning that right now most of the new acceleration work has to be done in radeon because the DRI support is not yet available in radeonhd. Once DRI support and DRM/CP functionality become available in radeonhd, you can look forward to being able to use brand new acceleration code with radeonhd as well ;)

[agd5f]

The ati/radeon devs are doing a great job, but in my opinion, RadeonHD is the way to go if you have R500+ hardware... at this early state I found RadeonHD to be rockstable already while ati/radeon has serious problems with TexturedVideo and 2D acceleration for me, and I think the RadeonHD driver will take the lead in performance and stability later this year...


Unfortunately, acceleration is the hardest thing to get working correctly in a video driver, especially the 3D engine (used by textured video and EXA render accel). Once radeonhd gets similar acceleration features, they will be in the same boat.

[agd5f]

For those in the know, will the AtomBios work with cards that have firmware for macs?

I have a 2600xt mac card that works perfectly well with the latest versions of RadeonHD.

I'd appreciate clarification on the difference between the firmware/bios in the mac cards and also if atom bios would/should/does support it.


Depends on the card. If it includes atom tables you should be fine. If not, you'll have to use bootcamp or we would need to include atom tables for your card.

[libv]

Here's the issue -- only the modesetting hardware changed between 4xx and 5xx. The acceleration hardware is largely unchanged, so the same code generally runs on both 3xx/4xx and 5xx parts.

With an emphasis on "generally".


Sure, but we already provided the documentation ;)


Partly. As far as i can remember, none of the PLL registers have ever been made public. Also, with both drivers now supporting RV620/635, the documentation for that still is not available. Since radeon fully depends on atombios (but hasn't much of a clue of what happens underneath), is there no more need for this information now?


We are providing complete documentation for what the registers do, and in some cases are creating new docs which explain how the pieces fit together. What we were hoping not to have to provide is the "set this register to 0x7... set that register to 0x0015fe2" level of detail since that was already coded and heavily tested in AtomBIOS.


So AtomBIOS means that you do not ever have to bother with providing actual programming information?

One of the design criteria for AtomBIOS was the ability for the driver to over-ride any table with a newer version if required. We have been using AtomBIOS for the Windows drivers for a few years now and have never had to patch a table, but the mechanism is there.

Given that ATI doesn't want people to flash the BIOSes of their cards, it is rather hard to get patched tables out to people. In that light, it is probably just Not Done to patch any tables.

Luckily the hardware is quite resilient, and i'm sure the windows/fglrx driver are full of workarounds like this: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commit;h=10e7636c02

Actually, that's not the case with AtomBIOS. We don't restrict you to specific modes. There is a traditional VBE / BIOS layer running on top of AtomBIOS which does have a fixed mode table, but that only affects VBE calls.

It does restrict things which real code would not restrict. The choice between PAL or NTSC is largely dependant on what is available in AtomBIOS.

[agd5f]

Luckily the hardware is quite resilient, and i'm sure the windows/fglrx driver are full of workarounds like this: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commit;h=10e7636c02


This is to workaround the fact that we only use atom for external tmds chips on r4xx cards, the rest uses the old code.

[libv]

Unfortunately, acceleration is the hardest thing to get working correctly in a video driver, especially the 3D engine (used by textured video and EXA render accel). Once radeonhd gets similar acceleration features, they will be in the same boat.

This is quite wrong. Modesetting always has been and always will be the single hardest thing to get right. With modesetting the demands and varying configurations are endless.

When acceleration works on one close enough related family of hardware, it will pretty much work everywhere. The user will not go around and suddenly change the whole layout there.

[libv]

This is to workaround the fact that we only use atom for external tmds chips on r4xx cards, the rest uses the old code.

So you're not using atombios to the full extent possible there? Just for those bits where you cannot be bothered?

[ethana2]

Look at the benchmark comparison between them on phoronix, pick the fastest driver for the card, stabilize it, and ship it.

Oh wait... don't tell me you didn't take bechmarks here.. I'm not seeing them. Am I missing something?

[Michael]

Look at the benchmark comparison between them on phoronix, pick the fastest driver for the card, stabilize it, and ship it.

Oh wait... don't tell me you didn't take bechmarks here.. I'm not seeing them. Am I missing something?

If only it were that simple... Let alone those benchmarks are old and simply the basic EXA/XAA performance doesn't tell the whole story of the driver. That's like saying pick Windows over Linux if in Quake you find better frame-rates.

[ethana2]

Ok, it may be harder for the stable versions they'd be looking to ship, but now I'm curious.

Could phoronix pull from today's code, compile both drivers and give OpenGL benchmarks?

[Michael]

Ok, it may be harder for the stable versions they'd be looking to ship, but now I'm curious.

Could phoronix pull from today's code, compile both drivers and give OpenGL benchmarks?

No, they aren't at OpenGL stage yet.

[agd5f]

This is quite wrong. Modesetting always has been and always will be the single hardest thing to get right. With modesetting the demands and varying configurations are endless.

I would disagree, but if that's what you believe, that's all the more reason to use atombios. It's been debugged by our bios and driver teams extensively since that is what our binary drivers and bioses use.

When acceleration works on one close enough related family of hardware, it will pretty much work everywhere. The user will not go around and suddenly change the whole layout there.

The user will try and spin the compiz cube with 10 eye candy plugins enabled or try playing stage 2 of some 3D game and wonder why the whole computer hangs.

[ethana2]

Oh.
*sigh* I wish Ubuntu had bi-monthly driver updates or something. I'm on Hardy now pretty much just for the latest drivers for our three intel GPU's.

[libv]

I would disagree, but if that's what you believe, that's all the more reason to use atombios. It's been debugged by our bios and driver teams extensively since that is what our binary drivers and bioses use.


Tell that to all those r100-r400 users that complain about 6.8.0 being a regression for them compared to 6.7.0.

The user will try and spin the compiz cube with 10 eye candy plugins enabled or try playing stage 2 of some 3D game and wonder why the whole computer hangs.

And will then disable DRI and do real work. Also, this user will not be the only person hitting that case. Everyone else who uses the exact same driver stack and close enough hardware will experience exactly the same with a wide range of 3d using applications.

[agd5f]

Tell that to all those r100-r400 users that complain about 6.8.0 being a regression for them compared to 6.7.0.

There was no atombios support r1xx-r3xx. If you don't want new functionality, stick with the old driver.

And will then disable DRI and do real work. Also, this user will not be the only person hitting that case. Everyone else who uses the exact same driver stack and close enough hardware will experience exactly the same with a wide range of 3d using applications.

Exactly. Acceleration is much harder get stable than modesetting. How many stable 3D drivers are there compared to drivers that can get a picture on the screen?

[bridgman]

As far as i can remember, none of the PLL registers have ever been made public. Also, with both drivers now supporting RV620/635, the documentation for that still is not available. Since radeon fully depends on atombios (but hasn't much of a clue of what happens underneath), is there no more need for this information now?

There's certainly still a need, but as long as you have the modesetting info under NDA *and* have a go-ahead to use it in an open source driver we're treating the release of 3d information as higher priority than getting the modesetting docs out to the public. On balance I think that is the right approach, but there are strong feelings both ways.

So AtomBIOS means that you do not ever have to bother with providing actual programming information?

Depends on what you mean by "programming information". We don't see the need to document what value should be programmed into each register, since it is not necessarily the same from chip to chip or even board to board. We do see a need to get register specs into developers hands. We also see a need for more "overview"-type documentation to help developers get started, but we didn't have any of that at the start of the project (nobody knows that better than you ;)) and hoped to follow an implementation path (AtomBIOS commands) which didn't need that information at the start.

Given that ATI doesn't want people to flash the BIOSes of their cards, it is rather hard to get patched tables out to people. In that light, it is probably just Not Done to patch any tables.

AtomBIOS table patching is a runtime event where the driver supplies the newer table contents, not a BIOS re-flash.

Luckily the hardware is quite resilient, and i'm sure the windows/fglrx driver are full of workarounds like this: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commit;h=10e7636c02

Yep -- the 4xx AtomBIOS definitely had some rough edges. It wasn't until the 5xx family where we started using AtomBIOS 100% in the production drivers.

It does restrict things which real code would not restrict. The choice between PAL or NTSC is largely dependant on what is available in AtomBIOS.

Yep. That was a deliberate decision IIRC (specific boards only supposed to be used with specific TV standards) although I don't remember the reason off the top of my head.

[airlied]

Tell that to all those r100-r400 users that complain about 6.8.0 being a regression for them compared to 6.7.0.



And will then disable DRI and do real work. Also, this user will not be the only person hitting that case. Everyone else who uses the exact same driver stack and
close enough hardware will experience exactly the same with a wide range of 3d using applications.

Most of the 6.7->6.8 regressions were purely to do with randr-1.2 support, and dropping zaphod (which I mostly put back since). We probably could have just called it version 7 and stated it wasn't going to work with current xorg.conf as well, but clearly without someone funding our work at the time, most distros wanted randr-1.2 working instead of zaphod and we listened to the majority. Since we both got jobs now, we have had more time to stabilise and add back things like zaphod.

Maybe disabling DRI is an option for Novell in the future, but we have users who want to run compiz and I'm sure you have some Xgl lovers internally as well.

Just switching off accel is going to be less and less a solution and we are going to have to put more and more time into fixing those sort of problems. We are in a better position to do this now than we have ever been before.

Dave.

[airlied]

This is quite wrong. Modesetting always has been and always will be the single hardest thing to get right. With modesetting the demands and varying configurations are endless.

When acceleration works on one close enough related family of hardware, it will pretty much work everywhere. The user will not go around and suddenly change the whole layout there.

You must not use any of the modern hardware I've worked with. Acceleration features on any modern hardware is never simple, modesetting is a lot lot lot easier.. Didn't you rip out the one useful acceleration feature for VIA hardware from unichrome (hw mpeg decoding). I think you need to actually do some accel work, copying it from radeon will make it easy as we will have debugged it already. We're nice like that.

Dave.

[libv]

The user will try and spin the compiz cube with 10 eye candy plugins enabled or try playing stage 2 of some 3D game and wonder why the whole computer hangs.

Check bugs on any driver out there. Most are "my monitor in this configuration doesn't work", "my vt doesn't restore" or "resume is broken".

[libv]

There was no atombios support r1xx-r3xx. If you don't want new functionality, stick with the old driver.

So users of r1xx-r4xx should not update to 6.8.0 at all?
So legacy means "deprecated".


Exactly. Acceleration is much harder get stable than modesetting. How many stable 3D drivers are there compared to drivers that can get a picture on the screen?
Learn to walk first, then run. Also, acceleration when it works on one family of graphics devices, will run unaltered on pretty much the whole range.

But do keep this story up. I'm sure that in different circumstances you will start saying the exact opposite.

[libv]

You must not use any of the modern hardware I've worked with. Acceleration features on any modern hardware is never simple,

Oh? And here i was, thinking that writing 3D drivers was going to be easier than ever. All i keep on hearing is that, once the infrastructure is in place, 3d drivers are trivial. I must have been listening to the wrong people i guess.

modesetting is a lot lot lot easier..

Oh? Are you the same Dave Airlie that usually claims to have been """involved""" with all major modesetting drivers? Like some kind of demi-god, knowing all and everything, being everywhere in ominous amounts?

Because next time you do talk about the importance of your "involvement" in modesetting, i will be calling you on this here.

So maybe you shouldn't change your story depending on how the wind blows. Someone, especially me, will be calling you to such statements. Just like i will continue to call you to how you failed to grasp the real concept of output abstraction.

Didn't you rip out the one useful acceleration feature for VIA hardware from unichrome (hw mpeg decoding).

Yes, and i subsequently rewrote the whole Xv subsystem underneath, making it the only implementation that triggers the different engines in the way the hardware designers intended. In about half the code too.

Also... Re-adding MPEG slice decoding took about 700loc (in my spacious coding style) with everything wired up correctly. About 1/12th or so of the original code.

Once you really know what makes the hardware tick, you really know how to code it up well too. Before that, you're just crapping around in the dark, stepping in your previous deposits all the time.

I think you need to actually do some accel work copying it from radeon will make it easy as we will have debugged it already. We're nice like that.

Just as nice as copying most of the hard modesetting work from radeonhd was for you i suppose.

[agd5f]

So users of r1xx-r4xx should not update to 6.8.0 at all?
So legacy means "deprecated".

If the want randr 1.2 support they should update. For the vast vast majority of users 6.8.0 works fine. The code was significantly refactored to support randr 1.2. Any large code change like that will have some fall out. I don't have every card and I can't test every combination. When bugs are reported we try and fix them.

[duby229]

Well, lets just except that we have differing opinions folks. There is enough room for two separate OSS drivers. No need to bicker or argue.

In the end it will be the end user who benefits. Lets just agree to disagree and continue to develop the drivers the way you see fit. We'll have two separate drivers that we can choose from. I think it is better this way and we should all be happy to have a choice.

[mattst88]

Differing opinions et al. are perfectly acceptable and totally expected.

Making a point of being rude is not. Only one person has done this. I don't know about elsewhere, but in this thread it is *not* a two way street.

[sundown]

The ati/radeon devs are doing a great job, but in my opinion, RadeonHD is the way to go if you have R500+ hardware... at this early state I found RadeonHD to be rockstable already while ati/radeon has serious problems with TexturedVideo and 2D acceleration for me, and I think the RadeonHD driver will take the lead in performance and stability later this year...

I just joined the Sidux waggon and plan to stay there forever :D

[The_Monkey_King]

I bought the GIGABYTE GA-MA69GM-S2H (Socket AM2 AMD 690G HDMI Micro ATX) last year in late August. It has been over 6 months and I still cannot use all the advertised features of the chipset.

Tell me when you all think you'll have all that stuff together and I promise I will come and test it.

Until then, my recommendation still is to use Windows XP and Intel chipsets for new HTPCs.

[agd5f]

I bought the GIGABYTE GA-MA69GM-S2H (Socket AM2 AMD 690G HDMI Micro ATX) last year in late August. It has been over 6 months and I still cannot use all the advertised features of the chipset.

Tell me when you all think you'll have all that stuff together and I promise I will come and test it.


Most things (HMDI, DVI, VGA, 2D, basic 3D, Xv, EXA composite accel) (except TV/Component) should work with the latest mesa/drm/radeon bits from git.

[ashrack]

Hello!
I am using Hardy Heron with the VESA driver.
My needs are pretty basic for GPU. I do lots of programing, web surfing, watching divx/xvid, x264 movies,...

So which driver would you recommend? And what would be the advantages over the VESA driver?

Sapphire Radeon 3850 256MB

[rbmorse]

At least we now know the real reason why there are two different open source Linux driver development efforts for ATI.

[bridgman]

Hello!
I am using Hardy Heron with the VESA driver.
My needs are pretty basic for GPU. I do lots of programing, web surfing, watching divx/xvid, x264 movies,...

So which driver would you recommend? And what would be the advantages over the VESA driver?

Sapphire Radeon 3850 256MB

For a 6xx family part you are only going to get acceleration from the Catalyst Linux (aka fglrx) driver today, but any of the open or closed drivers would probably work fine for you.

The radeonhd driver seems to work well for video playback via X11 output if you set AccelMethod to ShadowFB and have a pretty fast CPU. If you don't have a fast dual-core CPU, I would go with fglrx and use the TexturedVideo Xv option. The CPU will still struggle with HD H.264 decode but at least it will have an easier time.

[ashrack]

I have a pretty fast cpu. More info in the sig.
I do not want to use the FGLRX since I am still hearing bad things about FGLRX.

What would be the improvement over VESA driver if I went to RADEON or RADEONHD and which is more stable for 2d?

[d2kx]

The fglrx driver is working very well for many/most users now. Just install it, change your xorg.conf and add

Option "TexturedVideo"
and maybe
Option "TexturedVideoSync"

to your Device section.

For better 2D acceleration (still experimental, but works & improves the performance for me)

Option "Textured2D"
Option "TexturedXrender"

If you do not want to use the fglrx driver, I'd recommend the RadeonHD driver, built by git (because Ubuntu uses v1.1 which is three months old).

The improvement over Vesa is that you will have all the colours (I think vesa is only 16Bit - correct me if I'm wrong) and will have 2D acceleration (you should notice that things go slowly, e.g. when moving windows).

[Melcar]

The fglrx driver is working very well for many/most users now. Just install it, change your xorg.conf and add

Option "TexturedVideo"
and maybe
Option "TexturedVideoSync"

to your Device section.

For better 2D acceleration (still experimental, but works & improves the performance for me)

Option "Textured2D"
Option "TexturedXrender"

If you do not want to use the fglrx driver, I'd recommend the RadeonHD driver, built by git (because Ubuntu uses v1.1 which is three months old).

The improvement over Vesa is that you will have all the colours (I think vesa is only 16Bit - correct me if I'm wrong) and will have 2D acceleration (you should notice that things go slowly, e.g. when moving windows).

Textured Video should be enabled by default on some cards. It is on mine (HD2900XT) and according to Bridgman in a previous post, it should also be the case for all AVIVO chips:

As I understand it, for pre-Avivo parts (anything up to X1050) we enable VideoOverlay by default, since that arguably offers the best combination of video quality and low CPU utilization. On the Avivo parts (X12xx and up), which have a less capable overlay processor but more shader power, we enable Textured Video by default.

If you have a pre-Avivo GPU but are using a compositing desktop, you would probably want to enable Textured Video rather than VideoOverlay, but the installer isn't smart enough to do that for you yet.

http://www.phoronix.com/forums/showthread.php?t=6585&page=19

[bridgman]

Yep. The per-chip defaulting is pretty recent so I don't know if it's right in all cases, but that's certainly where we're heading and it seems to be working properly from what I have seen.

[chipsugar]

While all this documentation is good news for linux and for you OSS driver coders I'm curious as to when the r300 chip 3D support (and hence the radeon 9700 3D support) will be up to the level of the fglrx driver.

Would anyone who's looked at the dri source and the new documentation be able to hazard a rough, off the record, unofficial guess?

[Regenwald]

"benchmarks" :)
http://tirdc.livejournal.com/21263.html

[Tillin9]

As far as fglrx to radeon on r300 parts, I'm fairly sure radeon will be better for you unless you need OpenGL 2.x or raw performance. Of course if you really need either of those, the easy solution is to buy and newer card and use fglrx, with newer parts it has gotten a lot better. My experience is the open source radeon driver on r300 is that it is more stable and easier to configure/ use.

I've always had artifacting in OpenGL apps with fglrx (I've tried up to 8.42) on my 9700 Pro and on my 9500. Also, depending on release there were watermarking (artifacts in the corner of the screen), instability in Xv apps (i.e. I couldn't use tvtime), crashing the machine on logout, inability to get compiz to work regardless of what I did, and a number of other errors.

Radeon always worked more or less out of the bag, no artifacting, compiz works, etc. The downside is 2D performance had been slower than fglrx until recently. Now, with all the recent EXA work I think 2D is on par. 3D is around 1/2 to 1/3 speed and of course only up to OpenGL 1.3 is supported. The big annoyance here is WINE uses a lot of OpenGL 2.x features to emulate older DirectX 7&8 calls.

Please note, I'm not bashing fglrx in general. On my X850 XT at work it runs perfectly and has since 8.38, its just (I think) AMD/ATI is not actively testing r300 parts with it.

[bridgman]

While all this documentation is good news for linux and for you OSS driver coders I'm curious as to when the r300 chip 3D support (and hence the radeon 9700 3D support) will be up to the level of the fglrx driver. Would anyone who's looked at the dri source and the new documentation be able to hazard a rough, off the record, unofficial guess?

The general consensus seems to be that serious open-source 3D performance is not going to happen until both TTM and the Gallium re-architecture of the Mesa (3D) driver are in place. Best guess would be between 6 and 12 months.

I don't think the performance will be as high as fglrx but it should be pretty good.

[DragonionS]

I am voting for xf86-video-radeonhd. :) Great driver and I am looking forward for great performance on 3d. :)

There should be such driver with support from AMD.

[bridgman]

Note that neither radeon nor radeonhd have much to do with 3D -- that is all implemented in the mesa and drm drivers. The X drivers (radeon and radeonhd) just handle modesetting and 2D acceleration. They can either do 2D acceleration themselves or run over drm - but if you want 3D then the 2D acceleration needs to go through drm as well.

You need (radeon or radeonhd) plus mesa plus drm to get a full accelerated driver stack.

[DragonionS]

For now fglrx can't show video in compiz-fusion without blinking :( The open source drivers are giving 10-20 FPS in the 3d games in linux for my M56 videocard :(

But with radeonhd I've received more stable work than ati. I have X crashed 10 times a day with xf86-video-ati. With radeonhd - no crashes at all. It is important for me :)

P.S. Thanks for information about role of these drivers for ATI videocards. :)