OpenSUSE Says Farewell To RadeonHD Driver

[forum1793]

Thanks

I also say thanks to all. I used the radeonhd often. A couple of different times, the distribution changed kernels and fglrx/Catalyst would not compile. At that time, radeonhd was the ONLY driver that worked and allowed audio over hdmi. What would I have done with myself if I couldn't watch DVD's?

I've also never seen any significant improvement in speed between the two. This may be due to my slowish 780g IGP. I think by the time the newer "improvements" were integrated, the kms slowdown negated any improvement I might have seen.

Special thanks to Christian. I was a little wary at first as he used some name like deathhead or something like that which one might imagine could lead to nasty viruses or weird problems requiring reboots. But it worked pretty well.

To the radeonhd team, I wish you well in future endeavors. Time to move on to new things... like open hardware graphics (license free hardware, design in the public domain). Good also for CPUs. Challenge yourselves.

[daniels]

* Atombios introduced another level of abstraction: needless abstractions are simply a cause of bugs, and even though a driver should try to work with the hardware directly, and dealing with the hw bugs directly, it then gets denigrated to addapting to interface changes, not knowing what the hardware underneath does, and working around bugs in the layer underneath on top of possible bugs in the hardware.

funny, we've been making near on the same argument as to why we don't just want to take all of /usr/include/xorg now, call it our wonderful stable api, and bless it forever. (doubly so for mesa.)

i guess that's just another instance in a long history of us stealing your original ideas though?

[nanonyme]

Now. We wrote a proposal in may, and we got to put that plan into action, on the basis of direct communication through technical account managers on either side, and with you supposedly supplying technical information. One would think that, if there was an alterior strategy approved by AMD senior management, the direct communication that existed would have revealed this, in an open and honest manner, wouldn't it?

Actually there is another possible scenario to an elaborate scheme by individuals. That would be that AMD internal communication completely and utterly failed during one point. This happens from time to time in companies, however, I'm not sure it'd be that easy to get them to put a non-biased group to investigate internally what actually happened and then admit a failure with the way they've been handling things in one way or another. (whether that failure is having wrong guys running the project or lack of communication between guys running different parts of the project, I don't really want to start guessing)
Just out of curiosity: if they did that, would it satisfy you and allow you to put this to rest for good?

[crumja]

I've been watching this drama unfold with some amusement for a few years now. As a direct consumer given the choice between the two drivers, here were my thoughts (though some of them may seem trivial or stupid to experienced developers such as libv) as to why I chose and used the radeon driver rather than the radeonhd one. As you'll see, most of the reasons are practical rather than ideological.

1. More distros opted to use -ati rather than -radeonhd as the default. This meant more testing with a larger userbase, more "support", and easier configuration.
2. The speed of development. -ati gained more features quicker than -radeonhd did. Momentum built and developers flocked to the project, perhaps because of AtomBIOS usage.
3. Press coverage. Phoronix published many articles on how quickly -ati was advancing on r500+ modesetting. Little was said about -radeonhd other than HDMI audio.
4. Lack of stable releases. Yeah, you will tell everyone to build from git, but I'm just more reassured when I download and use a stable release, binary > source. Distros obviously think this way as for a long time, the -radeonhd driver included was limited to 1.2.x while radeon shot through the version numbers. Heck, even if the amount of actual change was the same, -ati just *seemed* like it had more activity.
5. My *own* perception that -radeonhd was just another suse-only project created for their own distro without any community-wide support. I had been soured on novell/suse projects for some time now. Some examples of this include XGL vs AIGLX, Mono, Banshee vs Rhythmbox, f-spot vs alternatives, beagle vs tracker.
6. I thought that the X.org developers would not allow two separate overlapping projects for the same driver. If they canned one of the two (as Daniel Stone eventually tried), it would be radeonhd.

Luc, thanks for telling the story of what happened behind the scenes. It's obvious that there was disagreement between all parties involved. It's unfortunate when a lot of manpower is wasted like this.

To conclude, the failure of radeonhd was perhaps initially due to technical things, but that was soon overwhelmed by marketing issues.

[libv]

Luc, it's probably fair to say that you *believed* the project was a tool used by AMD to get ATI under control, but by the time the project started AMD and ATI were already pulling in the same direction. AMD senior management approved a plan that was developed jointly between "AMD people", "ATI people", Dave and Alex. I know you guys worked hard on a separate plan but that was not the plan that we were following.

When the project started, it would have been great if someone had said "whoa, this isn't the plan we prepared" but instead your earlier comments suggest that you felt that I simply didn't understand the plan and was either incompetent or was dragging your plan off course for some evil purpose.

The plan I was asked to implement was based on using AtomBIOS to simplify the initial implementation and new GPU support on the modesetting side, since (a) we knew that acceleration (particularly 3D) was going to need a lot of attention, and (b) we believed that KMS would start to replace UMS relatively soon and so would require re-implementing the modesetting code anyways.

It would have been great if I had understood earlier that you felt your job was to "get ATI under control" rather than to help implement the AMD-approved plan.

This is another big lie of yours, because by now the timeframe is big enough that the difference between the original story and your current story, is large enough for it to be seen like that.

This is how you work, you tell one story one day, and then the next day, add a slight twist to it, until eventually, you end up claiming that you have always stated the exact opposite of the original story. And we at SUSE and even in AMD management suffered through this for far too long. You also have a tendency to help make things happen in a certain way, and then later go "Oops, is that how it played out, i could never have imagined that!" towards your superiors and your peers. Enough to piss them off, but not enough to get you into enough trouble for you to get moved aside.

Now. We wrote a proposal in may, and we got to put that plan into action, on the basis of direct communication through technical account managers on either side, and with you supposedly supplying technical information. One would think that, if there was an alterior strategy approved by AMD senior management, the direct communication that existed would have revealed this, in an open and honest manner, wouldn't it?

The reality is that we were, at no point, informed about you executing this 'AMD senior management approved' 'plan that was developed jointly between "AMD people", "ATI people", Dave and Alex.' that you are now talking about. That you were executing a different plan, well, i think we all became privy to that after a bit, but officially, you were supposed to be working along. And this is how you played it too, officially working along, with "unfortunate accidents" along the way.

You no doubt got to read the proposal we wrote in may, as well. You supposedly had this 3h long phonecall with Airlied in june, but that date is not exactly known to me, the actual content is of course not know, and i have no idea what parts of AMD knew about this. What i know is that the first Task Statement was being written up by the SUSE account/project manager (jack) and the SUSE developers before the 15th of june 2007, as i, not having joined suse yet, received it then for my input. When i was in Nuernberg on the 17th, to traipse the city for an apartment together with egbert, Emmes and Sndirsch were busy creating a graphics card wishlist for the 5k usd hw budget AMD had then given us. The first technical call that we had was on July 3rd, and it did definitely not include Alex Deucher, Dave Airlie, and i seriously doubt that you mentioned them in the call then. So, no real signs of this set in stone plan of yours in that timeframe.

Your claim that you were executing something approved by AMD senior management does not explain why you had to sell hiring Alex as hiring "someone to help you with documentation". While the SUSE developers had some idea about who you would actually be hiring (even thought you constantly tried to play us off as stupid, we, to your regret, weren't), i heard that some people inside AMD were not very happy with the way in which you handled this, and the way in which this was sprung onto them.

You just never even mentioned this plan you supposedly were working on, you also definitely never mentioned it even in April 2008, when, with the project under Executive Oversight, Markus Rex already was pretty bloody pissed when you then stated in that you had promised to go do AtomBIOS stuff to redhat the summer before. Would the normally very composed current SUSE VP be that pissed if he had in any way known about your plan, do you think?

Oh, and one cute post of yours (http://www.phoronix.com/forums/showp...2&postcount=48) caused a big manager meeting inside SUSE. There it was decided that, rather than pushing for your resignation (to follow the former AMD-redhat TAM Ted Donelly), to wind down the project and not endanger the AMD-SuSE relationship further. While the winding down was not communicated directly to me (the rest was), this is what i can now see had happened. Would you think that all layers of SUSE management would be so ticked off by your post if your strategy was known to them?

There simply was no such strategy communicated to SUSE Developers or SUSE management, ever. Heck, one would think that SUSE management would've been able to understand that there was such an alternative strategy in this VP call that you joined once about this project, to explain your actions. I would more lean towards AMD management at the time not being too happy about those actions of yours, and them also not knowing this plan of yours.

You're a liar. You never have played anything straight. Your stories are one way today, slightly different tomorrow, and next week the story will sound like it is now suddenly the complete opposite to the one of the week before. You should have been thrown out together with Donelly, but instead, you have been allowed to continue to damage free software and AMD, and as time passes, it becomes more and more clear exactly what damage is being done.

When did you last make any documentation available?

Oh, and KMS was just a brainfart in the summer of 2007. Jakob Bornecrantzer walked in off the streets, and then was handheld through creating a headerfile based on xf86 standard and randr1.2 header files just months before in march 2007. It still is not suited for enterprise use today, 3 years on, but the buzz around it (like with network manager and pulseaudio) drives customer demand towards it.

[bridgman]

The radeonhd project failed, as we were a tool used by AMD to try to get ATI under control. Quite a lot of the labour and love that we poured into radeonhd, with idealistic goals, trying to do everything right, all of that kind of died off with it, and this is why i am sour.

Luc, it's probably fair to say that you *believed* the project was a tool used by AMD to get ATI under control, but by the time the project started AMD and ATI were already pulling in the same direction. AMD senior management approved a plan that was developed jointly between "AMD people", "ATI people", Dave and Alex. I know you guys worked hard on a separate plan but that was not the plan that we were following.

When the project started, it would have been great if someone had said "whoa, this isn't the plan we prepared" but instead your earlier comments suggest that you felt that I simply didn't understand the plan and was either incompetent or was dragging your plan off course for some evil purpose.

The plan I was asked to implement was based on using AtomBIOS to simplify the initial implementation and new GPU support on the modesetting side, since (a) we knew that acceleration (particularly 3D) was going to need a lot of attention, and (b) we believed that KMS would start to replace UMS relatively soon and so would require re-implementing the modesetting code anyways.

It would have been great if I had understood earlier that you felt your job was to "get ATI under control" rather than to help implement the AMD-approved plan.

This round of distros are not using radeon modesetting *or* radeonhd modesetting. IMO the real event here has nothing to do with radeon vs radeonhd -- it's all about radeon/radeonhd user modesetting vs a new modesetting implementation in the kernel driver. A lot of great work, ideas and passion went into radeonhd, and some of the key ideas (eg output abstractions) live on in the KMS implementation.

The "event" here is nothing more than another consumer distro moving to KMS, and using the radeon driver because that's where KMS support was implemented. UMS drivers will continue to be important for enterprise distros until the currently shipping versions reach end of life, which I believe is years away.

[libv]

@nanonyme:

The radeonhd project failed, as we were a tool used by AMD to try to get ATI under control. Quite a lot of the labour and love that we poured into radeonhd, with idealistic goals, trying to do everything right, all of that kind of died off with it, and this is why i am sour.

But it was made to fail. In general, AMD couldn't get ATI under control. In particular, the manager responsible for SUSE changed, who also was the one responsible for Redhat. This meant that Mr Bridgman was able to play his games and pull his crap with impunity. Once this manager was "moved aside", the project was already too far decayed for this to be rescued.

We were put between AMD and ATI, and we did amazing things on very little information and sometimes active opposition from ATI. Once ATI was unable to stop the free driver, it took some time for another strategy to turn up. This was; hire someone for documentation help, officially, but inofficially, have him be one of the main driving forces behind a competing project; and with some help from some redhat people; kill radeonhd, regain control, and stop giving out information: get into an nvidia like situation, but with less crap being thrown, and keep fglrx alive and let it be the primary product.

This is why i am sour. We did an amazing amount of work, and achieved things that AMD was astounded by, under opposition of ATI. We did amazing things for free software too, the free documentation, the nice and accessible code we wrote, the fact that we have free software to support this hardware i think can also be largely attributed to us. But it all turned against us, and shortsighted public opinion thinks we were "the evil novell ones", which is unbelievably perpendicular to the truth, facts and history.

Me getting bumped from SUSE was completely unrelated. Novell panicked and threw out tons of people. Even in the rapidly growing SUSE business (OPS, 20-25% growth year-on-year at the time, which was maintained through the crisis too) they still decided to cut heavily. Axing works on social factors in germany: age, time with the company, married/kids, handicaps; so i never had a chance.

@bugmenot2:

Christian Koenig is/was astounding, he came out of nowhere, figured out hdmi, and fully and completely understood how our driver was put together. He was a real revelation.

[libv]

Thanks for the radeonhd driver, luc, mathias and egbert. I used it from the beginning. I think it's clean structure helped the hdmi audio developer really a lot.

You know, for months after having hired him, Bridgman claimed that Alex Deucher was unable to understand the structure of the radeonhd driver, and that this was one of the reasons for why he didn't want to work in that driver

But thanks, we needed a well-structured clean driver because we wanted long term enterprise support and we really put a lot of effort on that front too.

[nanonyme]

Thanks for the radeonhd driver, luc, mathias and egbert. I used it from the beginning. I think it's clean structure helped the hdmi audio developer really a lot.

Yeah, let me just be clear after that last bit with Luc that I do also agree that xf86-video-radeonhd was a good thing while it was actively developed and I'm happy it happened.
Personally I think the only reason why two drivers for same hardware was a bad thing is that it wasn't clear which driver X should use if it wasn't specifically defined but I suppose this might be a deficiency in how X handles drivers, not in xf86-video-radeonhd.

[bugmenot2]

Thanks for the radeonhd driver, luc, mathias and egbert. I used it from the beginning. I think it's clean structure helped the hdmi audio developer really a lot.