Radeon vs. RadeonHD Fighting Continues

[Zhick]

My two pence:
Since radeon is afaik a true FOSS-effort, I'd say nobody can tell the developers what they should be working on, except their employers if they have such.
I, for one, am very glad for their work, since imho they have produced the better driver.

[elanthis]

The job of the radeonhd devs is to create a working driver. They did it. Why can't to radeon guys spend their time more useful for other things, X for example has some room for improvement. Why have they to do the duplicated work?

The funny thing being that for my 780G chipset, the RadeonHD driver can't seem to get my screen to work worth a crap -- bad constant flickering, off center image, missing mouse cursor, etc. -- but the radeon driver works perfectly.

Welcome to Open Source, dude. We duplicate a lot of stuff. Because that's how you get good software. We have multiple Free Software/Open Source kernels, We have multiple desktop environments. Multiple word processors. Multiple everything, really. And the Free Software ecosystem is better for it.

Competition is good. For example, it lets developers try out radically different approaches to solving a problem (like with radeon vs radeonhd) and determine which one is best. The alternative would be to just make a decision and have no way to find out if it was the right one. RadeonHD has taken work from Radeon, and vice versa. Without both projects existing, it is entirely reasonable to assume that we might not have a driver as far along as either of them.

[bugmenot]

Yes, radeon will implement all the 3D-engine-based acceleration.

Could you explain a bit further? There's only a tiny bit of stuff missing from the r5xx support, and it's all pretty trivial/non-important (color controls for textured video, dynamic powersaving), and also missing from radeonhd, too.

Also, agd5f *has* helped radeonhd. airlied and I haven't, but that doesn't mean that we're being evil.

HDMI patches for r6xx+ are going to be ported over as soon as I have spare time and nothing more important like, say, Mesa work. :3 (Or class!)
The powersaving patches are woefully undertested IMO, and IIRC they are to be used "at one's own risk."
Also, like I said earlier, radeonhd isn't going anywhere. It's only been dropped from one build script, that's all.

I see it in that way: radeonhd was created in order to build a driver for R500+. Why did radeon even try to support these chips too, only because it is possible? I think the radeon guys should have seen that there will be two drivers and that that is never good. Now we have two good drivers and that makes no sense. If R600 3d is working both drivers will try to support these chips and this is a waste of resources. And radeon starts to port over the patches and the other way round. *This is just stupid.*
Why not let radeonhd support R500+ / R600+ and the radeon guys should implement something like a powersaving infrastructure in X which can be used by all drivers for changing the powerstates automatically or can be used via an interface with which one could set them without restating X?

The job of the radeonhd devs is to create a working driver. They did it. Why can't to radeon guys spend their time more useful for other things, X for example has some room for improvement. Why have they to do the duplicated work?

[libv]

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.

Many people have a very different view of how things played out.

[libv]

Yes, radeon will implement all the 3D-engine-based acceleration.

Last i heard, this is not where AMD wants to go. But maybe Mr Bridgman can give the ATI view of the world.

[yangman]

The powersaving patches are woefully undertested IMO, and IIRC they are to be used "at one's own risk."

Indeed.

FWIW, radeon already has the DynamicClockGating hooks for AtomBIOS, which is the only PM feature that's remotely reasonable to assume safe.

Frankly, I don't see the harm in having two separate drivers developing in parallel until the dust around KMS settles down. Beyond that, well, we'll just have to see.

[bridgman]

Most of the work in radeon these days is making use of kernel modesetting and memory management (GEM) across all the supported ASICs.

I don't believe anyone is sitting around bored.

[MostAwesomeDude]

Hm.
Is radeon going to implement support for R600 if 3d is working?

Yes, radeon will implement all the 3D-engine-based acceleration.

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

Could you explain a bit further? There's only a tiny bit of stuff missing from the r5xx support, and it's all pretty trivial/non-important (color controls for textured video, dynamic powersaving), and also missing from radeonhd, too.

Also, agd5f *has* helped radeonhd. airlied and I haven't, but that doesn't mean that we're being evil.

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.

HDMI patches for r6xx+ are going to be ported over as soon as I have spare time and nothing more important like, say, Mesa work. :3 (Or class!)
The powersaving patches are woefully undertested IMO, and IIRC they are to be used "at one's own risk."
Also, like I said earlier, radeonhd isn't going anywhere. It's only been dropped from one build script, that's all.

[sundown]

Coz one are RedHat the others are Novell

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