Almost A Decade Later, RadeonHD Stories Still Coming To Light

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

[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

[RussianNeuroMancer]

Maybe they want F32 disassembler by fail0verflow, but this ~300 lines of code is already published.

[bridgman]

The actual question is: If someone today wanted documentation to replace AtomBios, would AMD give at least everything that obviously some others have? And they have them probably without signs of restriction. If not, at least is there a man somewhere inside AMD to say the truth? Because when you hear that "we will be by you side" only to find out that things are actually different, well.

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 ?

[artivision]

That's a very charged way of putting it. It's not like anyone forced them to shut down, they just stopped getting paid. Why should someone be forced to subsidize their driver when another one is already out and working better?

Well, i don't speak for the entire driver, only for a sub-project to replace AtomBios. This project would have been merged by now.

The actual question is: If someone today wanted documentation to replace AtomBios, would AMD give at least everything that obviously some others have? And they have them probably without signs of restriction. If not, at least is there a man somewhere inside AMD to say the truth? Because when you hear that "we will be by you side" only to find out that things are actually different, well.

[smitty3268]

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?

That's a very charged way of putting it. It's not like anyone forced them to shut down, they just stopped getting paid. Why should someone be forced to subsidize their driver when another one is already out and working better?

[artivision]

Something like that. From what I saw, it was more of:
1. Bridgman sees that there are two projects separately working on OSS Radeon drivers, one using AtomBIOS, one not. Hooray, diversity!
2. AtomBIOS saves a lot of trouble for driver developers. Hence it's obvious to Bridgman that radeon will evolve faster than radeonhd. Hence he prioritises it. Too bad the radeonhd guys are so adamant about not using it, else the teams could be merged.
3. At some point libv bugs him about some technical details, which time permitting he resolves, but it is not critical. When the docs are released, he sends them to both projects.
4. libv and friends reverse-engineer stuff that is not very important for AMD. Hooray, no need to ask for docs on those specific cases, then, since both drivers benefit from the work. Open source software at its best.
5. There's a conference coming up, have to prepare something interesting to say. More familar with radeon, and they recently worked on something that will impress people, might as well present that.
6. Oh man, the latest docs have been cleared for release! Awesome. Will have to give them to the radeon team.
7. Ah shoot, I forgot about those radeonhd guys. Eh, no big deal, I'll just tell them to talk to the radeon guys.
8. Yay, we got clearance to hire a developer! Amazing. Now talking to them will be so much faster. The radeon project is making great progress, must hire someone from there.
9. libv is asking whether the person we just hired is working full-time on radeon. Well, no, not at the moment. Quite a pity, really; I should probably ask the higher-ups to actually pay Alex for that work, just think about how much faster the work would go!
10. What, the radeonhd project is folding? Aww man. I was hoping there would be more out of that, but I guess they just couldn't catch up. Nothing I can do now...

In other words, never attribute to malice what you can sufficiently explain by poor communication and lack of time.

The biggest news from this is that we got another confirmation that fglrx is a terrible driver. Surprise surprise.

Also:



Yeap! In the end we have AMDGPU, and it's fantastic!

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?

Amd should drop AtomBios and PSP from at least a 3% of Linux processors, ASAP.

[liam]

The stupid neither forgive nor forget; the naive forgive and forget; the wise forgive but do not forget.
-Thomas Szasz

The rest forget but don't forgive?

Edit:

andresdju Great proverb.

[andresdju]

Always brings this to mind:

In fact, in Spain we have this proverb: "Agua pasada no mueve molino" ("Past water doesn't move the mill"). Just a good coincidence with the Quijote picture.

[GreatEmerald]

Well, I succumbed to curiosity and read it all. I don't think there's really much there.

Basically it boils down to:
1. Bridgman called the Suse guys and started bugging them to use AtomBIOS.
2. They said no, and complained a bunch about it.
3. Bridgman started working more closely with RedHat instead.

Well, duh, of course he did, because they were going the direction he wanted to go in while you guys were fighting him every step of the way. That's just human nature.

Something like that. From what I saw, it was more of:
1. Bridgman sees that there are two projects separately working on OSS Radeon drivers, one using AtomBIOS, one not. Hooray, diversity!
2. AtomBIOS saves a lot of trouble for driver developers. Hence it's obvious to Bridgman that radeon will evolve faster than radeonhd. Hence he prioritises it. Too bad the radeonhd guys are so adamant about not using it, else the teams could be merged.
3. At some point libv bugs him about some technical details, which time permitting he resolves, but it is not critical. When the docs are released, he sends them to both projects.
4. libv and friends reverse-engineer stuff that is not very important for AMD. Hooray, no need to ask for docs on those specific cases, then, since both drivers benefit from the work. Open source software at its best.
5. There's a conference coming up, have to prepare something interesting to say. More familar with radeon, and they recently worked on something that will impress people, might as well present that.
6. Oh man, the latest docs have been cleared for release! Awesome. Will have to give them to the radeon team.
7. Ah shoot, I forgot about those radeonhd guys. Eh, no big deal, I'll just tell them to talk to the radeon guys.
8. Yay, we got clearance to hire a developer! Amazing. Now talking to them will be so much faster. The radeon project is making great progress, must hire someone from there.
9. libv is asking whether the person we just hired is working full-time on radeon. Well, no, not at the moment. Quite a pity, really; I should probably ask the higher-ups to actually pay Alex for that work, just think about how much faster the work would go!
10. What, the radeonhd project is folding? Aww man. I was hoping there would be more out of that, but I guess they just couldn't catch up. Nothing I can do now...

In other words, never attribute to malice what you can sufficiently explain by poor communication and lack of time.

The biggest news from this is that we got another confirmation that fglrx is a terrible driver. Surprise surprise.

Also:

Soon it will be a decade since we started the RadeonHD driver, where we pushed ATI to a point of no return, got a proper C coded graphics driver and freely accessible documentation out. We all know just what happened to this in the end

Yeap! In the end we have AMDGPU, and it's fantastic!