Almost A Decade Later, RadeonHD Stories Still Coming To Light

[nanonyme]

Ooh, conspiracy theories, lemme try too: The main reason libv hasn't yet given up and moved to do something else is he feels community supports him through all the stories by Phoronix over the years while Michael's main motivation is to get more ad revenues to fund his benchmarking site

[GreatEmerald]

Congrats, you really proved that Bridgman has done what he thought that was right. Since you are really that smart, can I ask you to prove why the other guys couldn't be able to continue their project in parallel and they had to drop it? Also what is so fantastic about closed code inside open community?

Well, I'd take it that the reason libv and others abandoned radeonhd is because of the paranoic us-vs-them pentality at that point. I'd imagine they would have been able to port the AtomBIOS bits to radeon, but since they saw it as their competitor, they didn't want to cooperate. I don't really get this competitor mentality in open source; for instance, the fact that radeon incorporated some of the radeonhd code should have been seen as a great achievement, not as "they stole our code!". In the end, it's a driver; if you are truly working to make users' lives better, then radeon coming up on top is great. Nowadays its support is top-notch, and that's what the devs were aiming for all along. Doesn't matter whose team did it, you should be happy that now it's done and makes everyone's lives better.

I guess what other commenters said is true as well; since the main project is radeon, SUSE cut the funding. After all, nobody really needs the AtomBIOS-free path, when the AtomBIOS path works just fine; throwing money at it is just a waste. That's what Bridgman predicted, too.

I don't get your question about closed code.

[L_A_G]

If that post is even close to being truthful then it really doesn't paint a very nice picture of Bridgman.

At best he's very much incompetent at communicating with multiple teams outside of the company at the same time and at worst he intentionally sabotaged the radeonhd driver effort by stalling the same information he gave to the radeon driver effort without any hesitation. Being a believer in the principle of Hanlon's Razor ("Never attribute to malice that which is adequately explained by incompetence") I'm personally leaning towards the former.

I suspect this could all have been avoided had they communicated using mailing lists visible to the public similar to the Linux kernel mailing lists (minus Linus' legendary rants) so that the radeonhd team could see what Bridman and the radeon team were talking about and the radeon team could see what Bridgman and the radeonhd team were talking about. That way most if not all of the ambiguity would have been cleared up and you wouldn't have had any of the ill will caused by Bridgman passing on important information to the the radeon project while leaving the radeonhd project in the dark.

[SomeoneElse]

After reading the post and also the blog, for me it was clear how this discussion would go.

Michael - was it worth it?

[L_A_G]

Michael - was it worth it?

Probably... Drama and flamewars always cause a spike in traffic.

[rene]

Well, I'd take it that the reason libv and others abandoned radeonhd is because of the paranoic us-vs-them pentality at that point. I'd imagine they would have been able to port the AtomBIOS bits to radeon, but since they saw it as their competitor, they didn't want to cooperate. I don't really get this competitor mentality in open source; for instance, the fact that radeon incorporated some of the radeonhd code should have been seen as a great achievement, not as "they stole our code!". In the end, it's a driver; if you are truly working to make users' lives better, then radeon coming up on top is great. Nowadays its support is top-notch, and that's what the devs were aiming for all along. Doesn't matter whose team did it, you should be happy that now it's done and makes everyone's lives better.

I guess what other commenters said is true as well; since the main project is radeon, SUSE cut the funding. After all, nobody really needs the AtomBIOS-free path, when the AtomBIOS path works just fine; throwing money at it is just a waste. That's what Bridgman predicted, too.

I don't get your question about closed code.

Well, interpreting BIOS script is usually not what you want to do in your kernel mode. I fully understand the developers pain form a security and stability standpoint. Do you want your crappy BIOS "script tables" to oops your kernel every now and then?

And btw. mode setting is one of the most trivial things on earth. Just poke some registers for connector probing and fill some regs with width, height, ppl, etc. That the vendor need to obscure these things is hilarious. There is no IP in that. And we do not even talk about all the high fidelity and indeed complex 3D engine bits here, ...

There is a reason virtually nobody likes ACPI. It is exactly this complex BIOS virtual machine code interpreter nonsense that causes stability and reliability issues up to the day.

[rene]

What we provide today is:

- header files describing data structures inside the AtomBIOS data tables
- header files enumerating the AtomBIOS command tables
- source code for the AtomBIOS interpreter that executes bytecodes in the AtomBIOS command tables
- source code for the wrapper functions which extract information from AtomBIOS data tables and execute AtomBIOS command tables

What else do you feel is required ?

Nobody wants f*cking table interpretation for something as simple as mode setting.
Certainly all this AtomBIOS clusterf*ck is more complicated than a plain old C file doing direct register based modesettting would be.

And nobody wants wrapper functions to BIOS table interpretation. And nobody wants wrapper glue to windows inherited DAL register programming either. Simply write native Linux code and get away with wrappers of wrappers, of interpreters of tables.

Any maybe finally Linux suspend and resume becomes more reliable, too ,-)

[duby229]

Well, interpreting BIOS script is usually not what you want to do in your kernel mode. I fully understand the developers pain form a security and stability standpoint. Do you want your crappy BIOS "script tables" to oops your kernel every now and then?

And btw. mode setting is one of the most trivial things on earth. Just poke some registers for connector probing and fill some regs with width, height, ppl, etc. That the vendor need to obscure these things is hilarious. There is no IP in that. And we do not even talk about all the high fidelity and indeed complex 3D engine bits here, ...

There is a reason virtually nobody likes ACPI. It is exactly this complex BIOS virtual machine code interpreter nonsense that causes stability and reliability issues up to the day.

I can definitely agree with the logic you present, but the facts of what happened just don't fit cleanly into such a stereotype. Radeon was getting modesetting support on launch day because of AtomBIOS. It was obviously the faster path to support. Keeping databases of tables about every chipset implemented on every card that every vendor produces in an open source project just isn't feasible and RadeonHD proved that beyond any doubt when it couldn't even keep up with something as simple as just modesetting.

[bridgman]

Nobody wants f*cking table interpretation for something as simple as mode setting.
Certainly all this AtomBIOS clusterf*ck is more complicated than a plain old C file doing direct register based modesettting would be.

And nobody wants wrapper functions to BIOS table interpretation. And nobody wants wrapper glue to windows inherited DAL register programming either. Simply write native Linux code and get away with wrappers of wrappers, of interpreters of tables.

Any maybe finally Linux suspend and resume becomes more reliable, too ,-)

I was answering Artivision's question about documentation to support making an open version of AtomBIOS - so all of the artifacts I mentioned would be required. Replacing the BIOS with native code is a separate issue, although (a) it would need most of the same information, (b) you would then be back with the original problem of handling all the different CPU instruction sets that we support today.

Note that AtomBIOS does a lot more than just modesetting.

[nanonyme]

I was answering Artivision's question about documentation to support making an open version of AtomBIOS - so all of the artifacts I mentioned would be required. Replacing the BIOS with native code is a separate issue, although (a) it would need most of the same information, (b) you would then be back with the original problem of handling all the different CPU instruction sets that we support today.

Note that AtomBIOS does a lot more than just modesetting.

Did you mean GPU instruction sets?