Almost A Decade Later, RadeonHD Stories Still Coming To Light

[alexThunder]

There was cookies? I didn't even get cookies :-(.

Turns out, Bridgman really was the bad guy :O

[mulenmar]

My understanding is that the -radeonhd code is used in AmigaOS development now. I'm glad that work hasn't gone completely to waste, especially as was a truly Free Software solution...of course, that benefit is lost in the proprietary environment, but perhaps AROS can use it?

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

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

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

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

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

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.

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

[RussianNeuroMancer]

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