Radeon vs. RadeonHD Fighting Continues

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

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

[TechMage89]

In that case, they might actually be good!

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

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

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

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

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

[Extreme Coder]

I'm not a X or driver developer (I'm just your average 15-year old game programmer ), I think RadeonHD should be default for R500+, while radeon should stick to the older cards.

[libv]

Okay, let's clear up a few things.

1) radeonhd is *not* being "dropped from X.org". It's only been removed from a build script. It's still hosted on the same git repos, still has the same web space and wiki pages.

2) While a lot of radeon developers (including me) feel that radeonhd is duplicated effort and does not bring anything interesting to the table, that does not mean that we are doing anything to sabotage their efforts, and in fact, radeonhd's internal 3D engine acceleration (EXA, Xv) is based directly on radeon's 3D engine code. Saying that radeon developers are trying to quash radeonhd is just silly. (Not to mention that nearly all of us are on both #radeon and #radeonhd on Freenode.)

3) Much of the code that used to be in DDX drivers has moved out of those codebases, and into separate projects. All OpenGL stuff is in Mesa, most modesetting has been ported to KMS (although KMS won't be mainlined for a bit...) Fussing about differences between the two drivers is going to become increasingly pointless.

4) There's no forking going on. Pure and simple.
~ C.

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.