R600/700 EXA X-Video Code Merged To Master

[bridgman]

Normally the X driver would have nothing to do with audio, but when the audio controller shares an HDMI connector with video the X driver needs to program the GPU to combine the audio and video signals onto the HDMI output.

The rest of the audio functionality is still handled by the audio drivers.

[libv]

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.

If you look at the timelines of the two drivers, then people have been copying stuff from radeonhd into radeon and re-inventing the wheel there all along.

When we started with radeonhd we decided from absolute scratch to be able to build a solid, modular and dependable driver suited for the enterprise market. We then, from the outset, also decided to copy parts of the radeon acceleration code (in a clean, modular form) as we knew that, from a hardware point of view, there would be a slight bit of overlap that would be relatively easy to handle. We would still end up with a clean and managable driver.

Notice how the original r5xx support in radeon borrowed more from radeonhd than it ever did from avivo. Notice how, while we at radeonhd were doing the hard labour to support new hardware (with ages spent on solid dotclock calculation routines and vt restoration issues, and finding out all those things that no-one was providing us information for), people were doing some quick and dirty r5xx accel things and claiming it was a solid solution and claiming it was the only solution.

This has been the game all along.

RadeonHD is an attempt to do things properly, to create a solid driver ready for the enterprise market, and as such, ready for average joe user. This means hard labour, not quick statements that boil down to "but it works on my machine". This is a gap in perception, but not in actual usefulness, that cannot be bridged. Quick and dirty will always have the big but rather useless statements. Proper code will always have less visibility, especially since a satisfied user is a silent user.

[Kano]

Do you want that radeonhd is preferred for r500+ hardware in X autodetection code? Also why did radeon enable dri by default and radeonhd not? I backported radeonhd for Xorg 7.1 to use it as better driver than vesa but currently I only backport radeon for Xserver 1.4.2.

[libv]

Do you want that radeonhd is preferred for r500+ hardware in X autodetection code? Also why did radeon enable dri by default and radeonhd not? I backported radeonhd for Xorg 7.1 to use it as better driver than vesa but currently I only backport radeon for Xserver 1.4.2.

That one is pretty straightforward: because we have different standards and we do not see dri support as fully stable yet. If, as a user, you want dri support, you better be aware of what you are doing, and therefor should take hurdle of enabling this option.

Again; big statements versus safe/stable.

[susikala]

Just to add my bit of experience into the discussion, for me radeon and radeonhd work more or less the same. The differences I notice (using a git version from two weeks ago of both drivers):

-radeon had tearfree xv, which is important to me, radeonhd hadn't (I hear this issue's been solved in radeonhd)
-for some reason I don't get, probably just differences in the way the code works, when I play _any_ video with radeonhd, the screen switches to black for 2-3 seconds and then video playback starts. Same thing happens when I close the video (but not when pausing or switching to full screen). On radeon, video playback starts and ends directly, no "buffering".

I have no idea why radeonhd acts like that or whether it's a bug or how it should be, but it's somewhat annoying. So even on a new chip (hd3200), radeon works better for me. This kind of beats the purpose of radeonhd from my point of view as a user.

Honestly, I've been following the git commits for both drivers lately for the r6xx-r7xx development branch, and it looks like the same code keeps being duplicated. Isn't it a waste of work?

[bridgman]

Most of the recent commits (adding 6xx/7xx acceleration) have been in areas where we have been able to keep the code pretty much the same between the drivers, so it's not like the work is actually being done twice.

[elanthis]

Personally, I'm still thankful that we had both drivers. Neither the VESA driver nor RadeonHD were able to actually bring up a useable screen for me for months, but the radeon driver worked right out of the box. (780G chipset.) Both now work wonderfully, of course, but if RadeonHD was the only option, I'd have been stuck.

The same goes for NVIDIA drivers. I had trouble getting either VESA or the nv driver to work with my old 6150 chipset, but nouveau worked fine as did the binary driver.

In a world where everything works perfectly, multiple drivers makes no sense. In a world where all software has bugs, a little choice goes a long way. I'd much rather live in a perfect world, but the reality is that I don't.

[Vighy]

In a world where everything works perfectly, multiple drivers makes no sense. In a world where all software has bugs, a little choice goes a long way. I'd much rather live in a perfect world, but the reality is that I don't.

You are my new personal guru

[Pfanne]

since i didnt want to open a new thread i just ask the question here:
do the open source drivers support compiz + 3d application? (im not speaking of r600/700, but ati cards in general)

[bugmenot]

since i didnt want to open a new thread i just ask the question here:
do the open source drivers support compiz + 3d application? (im not speaking of r600/700, but ati cards in general)

Yes. All cards before have 3d support now, even for many months now. R600/700 will follow hopefully soon. Whats missing and whats important is still power saving for notebooks.