Radeon vs. RadeonHD Fighting Continues

[oblivious_maximus]

EDIT - $^#@^%$#&$%!!!!

First update done; I added a bunch more information about Gallium, KMS, GEM, DRI2, RDR etc, tripped over the 10k char limit and lost everything. Bah.

Oh how I hate this feeling...
Now I used to copy to clipboard whole content before sending (mails, big posts, comments etc) - especially to avoid broken http sessions, Javascript or.. character limits... It's my new 'nervous tic' like frequent CTRL+S in editors.

It's All Text! could save you both much consternation, if you're Firefox users.

[reavertm]

EDIT - $^#@^%$#&$%!!!!

First update done; I added a bunch more information about Gallium, KMS, GEM, DRI2, RDR etc, tripped over the 10k char limit and lost everything. Bah.

Oh how I hate this feeling...
Now I used to copy to clipboard whole content before sending (mails, big posts, comments etc) - especially to avoid broken http sessions, Javascript or.. character limits... It's my new 'nervous tic' like frequent CTRL+S in editors.

[bridgman]

Someone should make a sticky about this.

I'll try to update the "what is AtomBIOS and all these different drivers ?" sticky to include Gallium and a quick overview of what each component does.

EDIT - $^#@^%$#&$%!!!!

First update done; I added a bunch more information about Gallium, KMS, GEM, DRI2, RDR etc, tripped over the 10k char limit and lost everything. Bah.

[idamlaj]

I agree 110% with you!

Gallium3D is the way to go, the actual way is just a waste of time. Please develop the new drivers for Gallium3D instead.

*sigh* . Please have a look at previous posts before making such comments:

http://www.phoronix.com/forums/showthread.php?t=13222

Someone should make a sticky about this.

[bridgman]

Depends on what you mean by "support"

A lot of the code is showing up and working in Fedora 10 today. I imagine it will start appearing in the upstream kernel over the next couple of months -- a good chunk is in 2.6.28 already. Consumer oriented distributions will probably start picking it up in the next few months, but it might take a year before it shows up in the enterprise distros (SLED/SLES, RHEL etc..).

I guess the best way to put it is that we are at the very start of the transition, ie we need to be supporting new ASICs with KMS as well as user mode drivers today, but modesetting in the X drivers will still be needed for a couple of years.

[rvdboom]

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

That's jolly good news. Is there any expected timeframe for supporting both?

[timofonic]

even better: drop and get rid of ati and radeonhd. develop a fist class gallium3d-driver, test and optimize it and make it an alternative the to proprietary fglrx. but it's keeping a dream

I agree 110% with you!

Gallium3D is the way to go, the actual way is just a waste of time. Please develop the new drivers for Gallium3D instead.

[Kano]

Well radeonhd is relatively easy to compile against older X versions, even Xorg 7.1.1 is possible without any backports - just without any 3d support, but at least there is a picture on the screen I personally could never test that driver because it only supports new hardware, I prefer one driver that supports all - especially when a new X server/mesa is used where 3d support is on for r500 too. When there are 2 possible drivers then you can ask yourself which driver is autoselected when you don't specify one in the xorg.conf - you would have to look into the logfile. And as the radeonhd does not enable all features possible by default it looks more like an experimental driver - for experience users who like to add extra options. I would not delete the radeonhd driver, but for the future it is of course better to focus on the all in one driver - or that ati loader which autoloads the correct one - if the code would be really better than radeon, the radeonhd could be autoloaded for r500+, but I don't think so...

[elanthis]

This is flat wrong. Competition is bad, the only reason to compete is when you're denied the opportunity to cooperate.

Again, wrong. Sometimes you don't want to cooperate. Sometimes you want to do things totally and absolutely differently.

Like, for instance, using AtomBIOS -- which radeonhd ignored for months. Or using CS, which only radeonhd is using at the moment. And so on.

Quite simply, the radeon and radeonhd WANT to compete, otherwise they WOULD be cooperating, because nobody is denying them the opportunity.

Open source works because of an open exchange of ideas. Competitors don't exchange ideas freely, only collaborators do.

Clearly you're living in a different reality, since we're talking about two competing Open Source projects.

Competing is what you're forced to do when everyone is closed-source proprietary, and nobody tells anyone else what they're up to. It's a waste of resources, it retards the advancement of technology, and it's just plain stupid.

By that logic, having any kind of discussion is just plain stupid. Everyone should automatically agree and automatically take the same approach to solving the same problems. I mean, it's dumb for two people to waste time thinking about opposing ideas when clearly they could have spent that same time and effort just working on one of those two ideas without the discussion, right?

That's what competition in Open Source code is. A debate. A debate that is worth far, far more than slinging words about, because it's a conversation in which ideas are expressed in code and in which winners are measured by results.

Code is just ideas. Two projects competing to solve the same problems is no different than two people debating two ideas to the solution. The code fork just happens to be more effective at actually reaching a conclusion.

In some cases, those conclusions result in a merger. Or the death of a branch. In other cases, both ideas continue to live on because there simply isn't a conclusion.

Take KDE vs GNOME. There is no winner. KDE and GNOME are both desktop environments -- and the naive make claims about wasted effort and duplicate work -- but the real fact of the matter is that each desktop project represents a different ideal of how a desktop should be constructed and how it should interact with users, and there is no easy conclusion that can result in a single codebase.

I don't think anybody expects radeon and radeonhd to live on forever. But they are still competing -- and with real results to show for that effort -- because neither camp knows for a fact that they have the "right way" of doing things. They might think their way is right, but it hasn't been proven.

It's only going to ever be solved by actually having the competing code bases to judge. You can't know whether one way is right or not without actually giving it a try.

But endless proliferation of branches always weakens a project as a whole, which is why merging back is so important.

Which isn't always possible. You can't merge two completely divergent approaches to solving a problem. It's the definition of unmergeable. Sure, you could slap both approaches into a single tree somewhere and add in a ton of build framework code and runtime logic to switch between internal approaches or something, but it's quite silly to think of that as better than just having two different packages that can (and do) merge code back and forth when possible and desired.

Competition is BAD. Multiple projects that duplicate effort to accomplish the same goal is BAD. *Single* projects composed of a broad group of developers with diverse viewpoints working toward a common goal is GOOD.

Technically, it IS a single project -- the X.org project. It IS a broad group of developers with diverse viewpoints working toward a common goal (getting Radeon R500/R600/R700 working flawlessly).

You seem to be implying that the radeon and radeonhd developers aren't aiming for the same thing. Or maybe you're implying that the fact the radeon and radeonhd drivers aren't just two separate folders in the same git tree is evil. You're DEFINITELY making it clear that you don't understand the word "competition" and that you seem to think it means "cutting throats and killing each other solely for the sake of being the winner despite the actual results," which is totally off the rocker.

ALL successful ideas -- be they software, machines, medicine, or even biological lifeforms -- are built by pitting opposing ideas against each other and seeing which is the winner. It is the very most fundamental principle of scientific research, the cornerstone of natural evolution, and the only true way to build the best software. Homogenized development does not fetter out the bad ideas, it does not challenge developers to build higher, and it encourages stagnation.

The fight between radeon and radeonhd will die when it is naturally time for it do so. That will happen when one driver falls entirely behind the other because its approach turned out to be a dead end, or when both drivers are already practically identical in all aspects because they've pulled the best ideas out of each other.

For all intents and purposes, radeon and radeonhd are just two experimental forks within the same over-arching project exploring possible solutions to a single component problem. You're just getting confused because they don't share a git tree.

[ovoskeuiks]

Unless radeon and radeonhd are somehow radically different in their approach to the problem there doesn't seem to be much point in developing both.

However the people who volunteer their time to a project are free to do whatever they want. Of course if someone thinks it's a stupid idea they are also free to tell them that.