The State Of Open-Source Radeon Driver Features

[mjg59]

Hi Matthew;

I had the same discussion with Dave a page or two back. I'm not even suggesting going that far at this point.

I don't understand your comment about "already written code". I'm sure you understand that for new hardware writing code is just the first step of what can be a very long process with a lot of rewrites and may never result in a release. It's possible that the info you received under NDA was incomplete and suggested that the code was going to be released very soon, if so please let me know privately and I'll try to fix that.

Maybe I'm misunderstanding your chip architecture, but my impression was that it was similar to nvidia - ie, a separate microcontroller that executed code to perform the power management operations. The code to drive that microcontroller clearly already exists, since fglrx uses it. For us to drive it would require us to reverse engineer the microarchitecture, write a toolchain and figure out how to integrate it into the driver. You're in a position to shortcut several of those steps.

Like I said, we could improve the existing static power management, but no matter how much effort we put into it it still wouldn't be good - I'd be amazed if it could even approach a level that you could plausibly describe as "adequate". There's just no motivation whatsoever to spend that much time in order to provide something of marginal benefit to users when the same amount of time would provide much larger benefits elsewhere.

[Asariati]

Is it worth trying to match fglrx with the current code ? I don't think so (other than for r600 and below). Is it worth improving the current code enough to give a bunch of current users full use of the profile mechanism (and maybe a few options in between), particularly on middling-old hardwere ? I think so...

So where would a new developer start working on that? I read half the morning through X.org-wikis and other stuff and still have absolutely no clue where to start looking for more info/guidance. Or I need a break because of information overflow

[mazumoto]

Yes, although AFAICS the biggest pain point for users is not lack of slick dynamic PM but not even having enough entries in the tables to use the current profile mechanism fully. First priority would seem to be interpolating between the low and high settings in the current tables.

I just have to answer on this: absolutely not. I do care about PM, but I don't care about static PM at all. If it's not dynamic and hassle-free, I'm not going to touch it. And I really can't understand how anyone could come to the conclusion to put any effort into static PM ... since I strongly believe that 99.9% of even the tech-savy linux users won't ever know about or use static PM. Things like that need to just work.

I can't help doing some more ranting: I'm beginning to doubt AMD's linux strategy in recent months - I've been faithful for a long time (since before I bought my 4870's) and had a lot of patience. But with the 4xxx generation apparently getting out-of-focus of development while still missing lots of features (like PM) and not gaining a lot of performance improvements anymore, it seems highly doubtful to me that cards from that generation will ever be generally usable with the open-source drivers. With generally usable I mean the often mentioned "within 10% of fglrx performance". I'd be happily satisfied with perormance at 70% of fglrx. Unfortunately it's nowhere near that in my experience - and I don't believe it'll get there anymore in the next 2-3 years while those cards will be still ok to use for gaming.

The problem is that while AMD releases docs and employs some developers, it doesn't seem to me that that their driver is much more advanced than nouveau. I can use r600g for X and some light 3D (say Quake Live) well enough, but I can do the same on nouveau on my GeForce 8600M. But I cannot use fglrx - since it never supports the most recent X server fast enough (I'm on gentoo). With the nvidia-blob, support arrives much faster and I probably could wait a week or two with updating X for the driver to support it.

So with nouveau I get a basic reverse engineered driver without any firmware-tainting like AtomBIOS that is fully open and a binary blob I can use when I absolutely need performance.
With r600g I get the same basic driver but with firmware-tainting through AtomBIOS, but I can't use fglrx since it's so damn slow to support new X versions. Well, fglrx isn't an option anymore anyway, since support for my cards got dropped.

And then there is the issue with radeonsi - still no usable support afaik - so it doesn't seem like it'll get any better with future generations. Although there are statements that HD8000 will be the first generation to see launch-day 3D support. I simply cannot believe that considering the awful state radeonsi is in.

I'd really like to support AMD, since I believe competition (against the big ones, nvidia and intel) is important, and I think that there are a lot of good ideas within AMD (like opening up docs or supporting coreboot), but at the moment I'd just buy lower performing and worse supported hardware. I believe AMD could really gain a lot if they really embraced the idea of opening up their stuff.

[airlied]

I just have to answer on this: absolutely not. I do care about PM, but I don't care about static PM at all. If it's not dynamic and hassle-free, I'm not going to touch it. And I really can't understand how anyone could come to the conclusion to put any effort into static PM ... since I strongly believe that 99.9% of even the tech-savy linux users won't ever know about or use static PM. Things like that need to just work.

I can't help doing some more ranting: I'm beginning to doubt AMD's linux strategy in recent months - I've been faithful for a long time (since before I bought my 4870's) and had a lot of patience. But with the 4xxx generation apparently getting out-of-focus of development while still missing lots of features (like PM) and not gaining a lot of performance improvements anymore, it seems highly doubtful to me that cards from that generation will ever be generally usable with the open-source drivers. With generally usable I mean the often mentioned "within 10% of fglrx performance". I'd be happily satisfied with perormance at 70% of fglrx. Unfortunately it's nowhere near that in my experience - and I don't believe it'll get there anymore in the next 2-3 years while those cards will be still ok to use for gaming.

The problem is that while AMD releases docs and employs some developers, it doesn't seem to me that that their driver is much more advanced than nouveau. I can use r600g for X and some light 3D (say Quake Live) well enough, but I can do the same on nouveau on my GeForce 8600M. But I cannot use fglrx - since it never supports the most recent X server fast enough (I'm on gentoo). With the nvidia-blob, support arrives much faster and I probably could wait a week or two with updating X for the driver to support it.

So with nouveau I get a basic reverse engineered driver without any firmware-tainting like AtomBIOS that is fully open and a binary blob I can use when I absolutely need performance.
With r600g I get the same basic driver but with firmware-tainting through AtomBIOS, but I can't use fglrx since it's so damn slow to support new X versions. Well, fglrx isn't an option anymore anyway, since support for my cards got dropped.

And then there is the issue with radeonsi - still no usable support afaik - so it doesn't seem like it'll get any better with future generations. Although there are statements that HD8000 will be the first generation to see launch-day 3D support. I simply cannot believe that considering the awful state radeonsi is in.

I'd really like to support AMD, since I believe competition (against the big ones, nvidia and intel) is important, and I think that there are a lot of good ideas within AMD (like opening up docs or supporting coreboot), but at the moment I'd just buy lower performing and worse supported hardware. I believe AMD could really gain a lot if they really embraced the idea of opening up their stuff.

God I hate when people like you think they are informed, atombios isn't firmware tainting, stop talking bullshit until you actually understand things,.yes you are probably right be disappointed, but you should probably learn what you are disappointed about or just state you are ignorant up front.

Dave.

[mazumoto]

God I hate when people like you think they are informed, atombios isn't firmware tainting, stop talking bullshit until you actually understand things,.yes you are probably right be disappointed, but you should probably learn what you are disappointed about or just state you are ignorant up front.

Aww, sorry, I guess I mixed up things there then. I thought the firmware that I need to install is for talking to AtomBIOS more or less. I probably got to that conclusion because of that long past argument between radeonhd and radeon developers - I've been under the impression that the radeonhd-folks didn't want any black-box-blobs in the driver whereas the radeon driver which leverages AtomBIOS needs such blobs. But I didn't follow the whole thing very thoroughly, so I might be wrong there too.
Yet I can't help it to like what the nouveau guys did with their "FUC" blobs - writing an open implementation for them. That basically was what I wanted to express by using the word "firmware-tainting".

Actually I'm not sure disappointed is the right word here - I was well aware that the open drivers might never get anywhere near as good as suggested back when I bought my cards. I'd rather call it frustrating to see that while AMD has (in my opinion) the better philosophy of opening things up, it doesn't really come to fruitition - in some aspects it even seems worse by being bound to NDAs and maybe even less community interest (because everybody just waits for AMD to deliver whereas with NVIDIA it's crystal clear that it must be done by the community).
Hence it's not a personal thing of disappointment, but rather a hypothesis that while NVIDIA doesn't have an open strategy, their model might be no worse for open source than AMD's while customers seem to gain by their way of doing things. (Which I want to repeat is quite sad).

Basically I wanted to nudge bridgman with that, not you ;-)

[barkas]

God I hate when people like you think they are informed, atombios isn't firmware tainting, stop talking bullshit until you actually understand things,.yes you are probably right be disappointed, but you should probably learn what you are disappointed about or just state you are ignorant up front.

Dave.

Uncalled for. Apart from that he's pretty much spot on.

[manmath]

...... I'd rather call it frustrating to see that while AMD has (in my opinion) the better philosophy of opening things up, it doesn't really come to fruitition - in some aspects it even seems worse by being bound to NDAs and maybe even less community interest (because everybody just waits for AMD to deliver whereas with NVIDIA it's crystal clear that it must be done by the community).....

Opensource AMD Graphics Driver is a pipe dream!
Remember when AMD Fusion Series released, when the opensource driver for it was tauted about? Yes, it's been more than two years. The development has almost been static. Funny enough but true - opensource graphics driver for AMD E350 is much slower than the graphics that came with Pinetrail Atom chips. Meaning, it makes no sense to use those graphics drivers.

What's more the fglrx driver integration into linux is not that smooth either. It's buggy and complicated compared to propriatary nvidia graphics.

#1 Use either Intel or Nvidia graphics if you're looking for satisfactory performance on linux
#2 or Turn to Windows and use catalyst - it's great, very economical and feature complete

[curaga]

I beg to differ. The 3150 - a repackaged 945 - is not faster than the E-350/450, both running open source drivers.

Source: own both.

[disi]

I beg to differ. The 3150 - a repackaged 945 - is not faster than the E-350/450, both running open source drivers.

Source: own both.

I totally agree, even my AMD C-50 netbook is faster than the Intel Atom gpu

http://openbenchmarking.org/result/1110234-GR-1110220LI26

And those tests are quiet old, there has been a lot of improvement for the radeon driver in the meantime...

//edit: and with a proper dedicated card, I can compete with the catalyst driver on a new A-10 chip (at least with Urban Terror):

http://openbenchmarking.org/result/1211123-BY-1208141BY14

[Ansla]

Opensource AMD Graphics Driver is a pipe dream!
Remember when AMD Fusion Series released, when the opensource driver for it was tauted about? Yes, it's been more than two years. The development has almost been static. Funny enough but true - opensource graphics driver for AMD E350 is much slower than the graphics that came with Pinetrail Atom chips. Meaning, it makes no sense to use those graphics drivers.

What's more the fglrx driver integration into linux is not that smooth either. It's buggy and complicated compared to propriatary nvidia graphics.

#1 Use either Intel or Nvidia graphics if you're looking for satisfactory performance on linux
#2 or Turn to Windows and use catalyst - it's great, very economical and feature complete

The only thing that might be better with an Atom is video playback (E-350 with r600g certainly does not have hardware acceleration, not sure about Atoms). If an Atom is faster at anything else then E-350 + r600g you either have a defective unit or your software stack is messed up. Try a liveusb with the latest release of Fedora for example to see if it's a software problem.