R600/700 EXA X-Video Code Merged To Master

[bugmenot]

The radeonhd driver was actually the third, not the first -- we already had airlied's unreleased 5xx support in radeon and the avivo driver before starting work on radeonhd.

But that does actually not matter at all, because the driver was never released due to the NDA.

We proposed replacing both of those drivers with a new driver built over the atombios routines, and the developers working on radeon and avivo felt that was a good plan.
So far so good; there would be a new driver based on atombios, supporting 5xx and up, and everyone would support it.

Ah, there is the problem. You wanted 'of course' the use of atombios, but did not discuss that with the devs. Otherwise this could not have happened in that way.
I don't know exactly about the technical reasons (only that atombios is kind of proprietary and helps to support newer cards more easily in the future) and it probably does not matter, but if there are people writing a good driver for the cards, and it works, why isn't that enough? And today even radeonhd supports atombios, but the work on radeon still goes on?

I still think it would be the best to stop supporting new chips on one driver, in order to have exactly one driver for the new cards. That gives better stability of that driver because every bug is reported to "that" driver.

[agd5f]

But that does actually not matter at all, because the driver was never released due to the NDA.

Dave's code was never released but avivo was released and a few distros actually offered it as an option.

http://cgit.freedesktop.org/avivo/xf86-video-avivo/

[Timo Jyrinki]

And today even radeonhd supports atombios, but the work on radeon still goes on?

As your previous point (assuming you are the same one using a bugmenot account) was that radeonhd was first, while actually radeon was the first (of those two) with atombios support, shouldn't now radeon be kept because it was the first with that support? Or avivo

I still think it would be the best to stop supporting new chips on one driver, in order to have exactly one driver for the new cards. That gives better stability of that driver because every bug is reported to "that" driver.

There is nothing to back up the claim that somehow limiting a driver's supported chipsets would magically bring quality improvements. The codepaths are different so cards of various eras can be handled separately. Also, r500 is quite close to r300-r400.

The developers are mostly happy nowadays, so I think us users should just shut up and use whatever our distro provides. It's easy for developers to submit code to both drivers, and if viewing optimistically, really the two somewhat different code-bases, now that they already exist, are for everyone's benefit as different kind of bugs can be spotted in either of them and maybe something gets fixed that would otherwise been left unfixed.

It's more like "nothing to see here, move along" situation.

And indeed as was noted earlier in this thread, the r6xx-r7xx branch is now also merged to radeonhd.

[bugmenot]

There is nothing to back up the claim that somehow limiting a driver's supported chipsets would magically bring quality improvements.

In radeonhd the command submission (CS) was cleaned up, it is not only less support for older chipsets.

Also, r500 is quite close to r300-r400.

And from R600 on it is more "new". So imo it makes sense to have a driver only for newer chips.

The developers are mostly happy nowadays, so I think us users should just shut up and use whatever our distro provides.

I see that radeon is used everywhere instead of radeonhd, although the latter has more features. Maybe the users would be more happy with one driver.

It's easy for developers to submit code to both drivers,

Seems not to be the case, because audio over hdmi is still only in radeonhd and tear free video watching was a very long time only in radeon...

and if viewing optimistically, really the two somewhat different code-bases, now that they already exist, are for everyone's benefit as different kind of bugs can be spotted in either of them and maybe something gets fixed that would otherwise been left unfixed.

That is in my opinion not true either. Many bugs only get reported in one of the drivers and so it is less likely that one driver works with as many cards as it would be possible if all bugs got reported to that driver.

It's more like "nothing to see here, move along" situation.

For me it's just stupid. And even more stupid that most distributions use radeon and not radeonhd, although radeonhd has audio over hdmi support.

And indeed as was noted earlier in this thread, the r6xx-r7xx branch is now also merged to radeonhd.

I know and it was developed in radeonhd first.

Sorry for bringing this up again.
I just can't understand it. I'll be quite now.

[MostAwesomeDude]

In radeonhd the command submission (CS) was cleaned up, it is not only less support for older chipsets.

And from R600 on it is more "new". So imo it makes sense to have a driver only for newer chips.

I see that radeon is used everywhere instead of radeonhd, although the latter has more features. Maybe the users would be more happy with one driver.

Seems not to be the case, because audio over hdmi is still only in radeonhd and tear free video watching was a very long time only in radeon...

That is in my opinion not true either. Many bugs only get reported in one of the drivers and so it is less likely that one driver works with as many cards as it would be possible if all bugs got reported to that driver.

For me it's just stupid. And even more stupid that most distributions use radeon and not radeonhd, although radeonhd has audio over hdmi support.

I know and it was developed in radeonhd first.

Sorry for bringing this up again.
I just can't understand it. I'll be quite now.

Here's all I have to say that hasn't been said before:

The only compelling feature in radeonhd but not in radeon is HDMI audio support, which 1) should probably be in DRM and not DDX and 2) hasn't been ported because I don't have the HW (HDMI audio) and nobody else really cares.

~ C.

[quintesse]

Here's all I have to say that hasn't been said before:

The only compelling feature in radeonhd but not in radeon is HDMI audio support, which 1) should probably be in DRM and not DDX and 2) hasn't been ported because I don't have the HW (HDMI audio) and nobody else really cares.

How about talking to the one that did the development for radeonhd and ask if his code can be included in the radeon driver? Or if it can't be copied easily if he would be willing to help out?

Others I'm sure would be willing to do the testing, I know I did when the first code came out for the radeonhd driver.

[MostAwesomeDude]

How about talking to the one that did the development for radeonhd and ask if his code can be included in the radeon driver? Or if it can't be copied easily if he would be willing to help out?

Others I'm sure would be willing to do the testing, I know I did when the first code came out for the radeonhd driver.

It has to go into the kernel, not the other DDX. HDMI audio setup should be in DRM, and that makes all the difference.

Additionally, it's kind of hard to develop code, period, without local testing HW.

[bugmenot]

The only compelling feature in radeonhd but not in radeon is HDMI audio support, which 1) should probably be in DRM and not DDX and 2) hasn't been ported because I don't have the HW (HDMI audio) and nobody else really cares.

The point is: I don't ask myself why radeon has no support, I ask myself why radeon is the default driver and not radeonhd in most disrtibutions.

It is probably more work to copy the audio over hdmi support to radeon instead of changing the default driver to radeonhd.

[Ex-Cyber]

I don't ask myself why radeon has no support, I ask myself why radeon is the default driver and not radeonhd in most disrtibutions.

It doesn't get them anything to add radeonhd as a default. They'd just be stirring up a lot of trouble by making some users' experiences better and other users' experiences worse (radeonhd can very well be worse on R600+, depending on which bugs you run into).

[Ant P.]

How much of the audio support depends on the X driver? I would've thought that could be solely handled by ALSA/OSS, but apparently not.