OpenSUSE Says Farewell To RadeonHD Driver

[nanonyme]

libv, you seem awfully sensitive about all this.

Regardless of everything else, you'd think getting sacked from the project would make a person sensitive.

[libv]

libv, you seem awfully sensitive about all this.

Admittedly I haven't been involved in all the behind the scenes stuff, but from what I've seen here no one is really saying radeonhd wasn't useful. Lots of good code came from it and got copied back into the main driver, they're just saying that once -ati gained the support it needed then continuing development on radeonhd was wasteful. And it seems like the main reason that even happened in the first place was because radeonhd didn't want to use atombios and everyone else thought that was stupid.

Once KMS was being used, is there even a big difference in the code anymore?

Just like with creating a separate driver, we had the atombios discussion too (and now i am thinking, again: oh please, not this shit again).

* Atombios is no wonderous miracle. It is a BIOS, with all the problems of a BIOS: the code is not meant to be looked at, nobody can compile a fixed version for himself, even worse, ATI does/did not allow anyone to flash their cards.
* Atombios does not hide away hardware details, and a new updated interface comes out with new hardware families with new features. Worse still, gratuitous interface changes happen even within hardware families, sometimes with no flagging of the different interface.
* 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.
* We were forced to RE the lot anyway, as ATI barely gave us any information of what was happening behind the scenes or how we were supposed to use things properly.
* Atombios is buggy, and no-one can help you when it is buggy. As free software developers, we could not depend on being bug-per-bug compatible with fglrx or the windows drivers.
* Once one board of a family was ported, we could depend on the C code and fix the C code when issues occur (we had a nice one where atombios did not do the CRTC display disable wait properly from r500 through rv610/630; it was fixed in 620/635, which made me revisit the code, and have all the hardware before function perfectly as well).
* We wanted to use AtomBIOS ASICInit, as it is vastly preferred over running the full int10 BIOS. It took us ages to get any information on how to use ASICInit, in the end Bridgman set us up a phonecall with some fglrx developers. When asked, one of the guys said: "I don't know how to use ASICInit, we just use int10". Bridgman then quickly ended the call, and we never got to speak to anyone else inside ATI again. We ended up REing it, to find out how to use it.
* Because we were using ASICInit, we were using atombios in radeonhd. So stating that we were not using atombios at all is a blatant lie. We did not use atombios to the full extent possible.
* Atombios only hides away parts of modesetting and power management. It fails to provide other valuable information that we had to find out ourselves. In order to find out ourselves, we had to gain more complete knowledge of the hardware anyway, which meant that we had to RE anyway, at which point writing some C code is just obvious. Especially since many of the tables in there are just handling trivial things which can easily be transformed into C.
* Some of the atombios tables, for instance, for i2c, make poor use of the hardware or was completely useless.

Most significantly though: Bridgman, from the very start, was not exactly cooperative with SUSE. Atombios was his main stick to bash us with (which he has done on these forums too, which is why you now brought up atombios). Once egbert added slightly more atombios dependance to the radeonhd driver, bridgman seemlessly found another stick to bash us with.

Again, atombios or no atombios, this was not a technical discussion at all, because technically, there is only one solid answer.

Somehow, with how this all was handled, i am sure that, even if we did make the full possible use of atombios from the start, there would still have been an attempt to reinvent things by Dave Airlie and Alex Deucher.

Now, if you still are unsure, this here is a patch just posted days ago:

http://www.mail-archive.com/[email protected]/msg49802.html

How can one still claim that having this functionality in C, which works for every version of at least R500, R600 and R700, is not better?

[psychaos]

First post here.
I just want to say a big thank you to all the coder involved. Beeing them working on radeon or radeonhd.
You should be proud of yourself.

Sorry for my bad english.

[libv]

Regardless of everything else, you'd think getting sacked from the project would make a person sensitive.

Well, getting sacked from suse was in absolutely no way related to radeonhd: there were 25 developers dumped from suse on that one day, in a panick reaction from Novell to the financial crisis, and AMD and SUSE were already not pushing the project for several months anymore (even SUSE management gave up hope that AMD would get bridgman and ATI under control: AMD was struggling for survival, ATI graphics cards and chipsets were making more money than cpus).

[nanonyme]

Well, getting sacked from suse was in absolutely no way related to radeonhd: there were 25 developers dumped from suse on that one day, in a panick reaction from Novell to the financial crisis, and AMD and SUSE were already not pushing the project for several months anymore (even SUSE management gave up hope that AMD would get bridgman and ATI under control: AMD was struggling for survival, ATI graphics cards and chipsets were making more money than cpus).

I didn't know the exact reasons nor is it any of my business. I just know that I'd be annoyed if I was just doing something I thought was cool and then someone decides to simply pull the plug. It's a human reaction. If you can honestly say that didn't come into your mind at all, then I apologize for the misjudgement.

[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.

[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.

[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.

[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.

[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.