Radeon vs. RadeonHD Fighting Continues

[MostAwesomeDude]

1) it was dropped without consulting the parties involved, quite deliberately so. I wonder what i'll hear from daniels this time round when FOSDEM (which supersedes XDS now, and which never cost Xorg more than 500EUR ever) needs some funding help from the Xorg board again.

2) It is radeon that duplicated effort, the timeline of support in both drivers should tell you exactly that. There was always going to be some duplication on the r5xx as only the modesetting engine was exchanged there.

3) Good luck convincing linus on KMS, if even GEM is getting that much flack.

4) RadeonHD was forked by Redhat and alex deucher. There is no other way of putting it. If anyone is to be blamed for duplication of effort, then it's those people.

1) Yeah, this is true. On one hand, kind of a dick move. On the other hand, really not the end of the world; Ubuntu and Suse still ship radeonhd by default and autodetect with it before radeon IIRC, and I haven't heard any plans to change that. It's just a build script.

2) Don't be silly; all of us duplicated xf86-video-avivo. :3

In all seriousness, this is like saying that the nouveau project has duplicated the functionality of xf86-video-nv. Technically true, but not the reason for either project.

3) Yeah, Linus was a hard sell. I remember him cursing us out during Linux Plumbers. Basically, we all agreed about KMS and GEM:
- KMS is the way it should have been done in the first place
- Switching from TTM to GEM was silly since so much effort had been put into TTM, but Intel was already into it and nobody could really object since Alex and Dave had already figured out how to put GEM on top of TTM guts
- It's gonna be a rough transition, but it only needs to be done once
- All the DDXs need to have dual-compatibility, both pre-GEM/KMS and afterwards, and for Intel, GEM and KMS can be split

But yeah, he was not happy about it.

4) Well, um, I'm not really sure what to say. I don't think there's any commits in either repo which were cherry-picked from the other. There's some code in radeonhd which is from radeon originally, but I didn't really think there was any straight-out forking...

~ C.

[Dragonlord]

Forking is whenever a project splits from a main development trunk and works independent ( aka patches/commits into one repo doesn't affect the other repo ). Forking is not about "mindset" but about "forked repos".

[bulletxt]

the most important thing here is that AMD still hasn't released full documentation after all this time. this is the worst thing. these internal stuff between radeon and radeonhd are just gossip to fill websites threads. nothing will change to the end user.

so yes, the real fighting is me, a user like a bunch out there vs AMD and:
1: their eternal shitty fglrx driver. it's worse than Star Wars, it never seems to end.
2: their totally incomplete documentation release

that's all I have to say about this sh*t.

[bridgman]

Remember there are at least three unreleased episodes in the Star Wars arc. I expect Star Wars will outlive all of us.

Other than the 6xx/7xx 3D engine setup (in the pipe now, dev work going on in parallel) and some basic power management (5xx already happening, 6xx/7xx will follow 3D) what do you think is "totally incomplete" ?

We are going to look into the possibility of providing some video decode info (IDCT if not UVD) and are going to try to re-release some of the existing docs for older chips without NDA, but other than the above two areas I believe we have released everything I said we would.

[deanjo]

Remember there are at least three unreleased episodes in the Star Wars arc. I expect Star Wars will outlive all of us.

Unfortunately George said he isn't doing the final 3 episodes.

[TechMage89]

In that case, they might actually be good!

[reavertm]

I guess what Luc ment about "duplicating effort" was that xf86-video-radeonhd driver was supposed to support r5xx chips and above - what was the main target for radeonhd.
And then suddenly David Airlie came up with preliminary r5xx support in xf86-video-ati drivers... - this is what I as radeonhd user received as "what's that supposed to mean?". I guess that was the point that started this whole "competition" issue - because radeon drivers has "crossed the Sacred Ground" as they rendered radeonhd efforts obsolete.

[bridgman]

Honestly, if it were that simple this would have been resolved a long time ago. When we started the project there were two native modesetting drivers and teams - Avivo (public, reverse engineered) and a private effort led by Dave written using NDA information. Dave had contacted us about releasing his driver but we didn't really have enough of an open source plan at the time to give him any kind of quick answer, so that project more or less died.

Both groups agreed to wind down their native modesetting work in favour of a new atombios-based driver initially written by Novell. When radeonhd came out as another native modesetting driver things got heated very quickly. The obvious argument from the existing driver project teams was that if the new driver was not going to be atombios-based then there was no justification for getting rid of avivo in the first place.

In other words, everyone knew radeonhd was going to be a fork but that was ok since the goal was to get an atombios-based driver. Once radeonhd was released as a native modesetting driver rather than being atombios-based, it stopped being "a blessed fork" and things started to get ugly. The radeon and avivo developers were still looking forward to an atombios-based implementation and so implemented atombios-based modesetting in radeon.

We eventually got atombios-based modesetting in radeonhd (and a nice implementation at that) but by then the radeon and avivo developers were quite happy with the radeon implementation and saw no need to change.

And that's where we are today.

[bugmenot]

Hm.
Is radeon going to implement support for R600 if 3d is working?
And why can't the radeon guys just perfecting the support until R500 or ask the radeonhd guys if they could help them if they're bored instead of "taking them their work away"?

Radeonhd works so great here and there are different patched like powersaving and hdmi audio that do not exist for radeon, would be bad if radeonhd would disappear only because one man made a bad decision.
Thanks.

[sundown]

Coz one are RedHat the others are Novell