Tear-Free Acceleration For ATI EXA, Xv

[an0n1m0us]

I'm completely confused.

AFAIK *before* AMDTI disclosed details about their cards, there was one open source driver trying to support ATI cards through reverse engineering. Is this correct? Was this the xf86-video-ati driver?

AFAIK *after* AMDTI disclosed details abou their cards, xf86-video-radeonhd was likely to take over the open source ATI driver mantle and xf86-video-ati was in it's death throes.

What has changed? Why didn't xf86-video-ati die? What is the point in confusing end users with two open source drivers for (largely) the same hardware? Where is xf86-video-radeonhd at the moment?

When will ATI cards finally "just work", "out of the box", on most Linux distros?

I hear a lot of news about different developments here on Phoronix but I'm confused about the bigger picture context.

[mityukov]

Sorry, is EXA-support enough for Compositing on itself?

I mean, do I need to compile Mesa with the latest HW support, in order to have KWin 4's (or Compiz's) Desktop Effects working?

Or, it's now enough to install the latest build of xf86-video-ati driver?

[bridgman]

I'll answer the easiest question first. There is a delay between having drivers available in git and having them included in "out of box" distros, typically 6 months or so.

I think the modesetting driver support has been around long enough that most new distros include that support out of box. 3D acceleration for 5xx and rs6xx is more recent so is not included in the current crop of distros (other than F9) but should show up in the next round of distro releases.

re: EXA and compositing, as I understand it full EXA is enough to support some compositors (eg. Metacity) but you need OpenGL for Compiz. Not sure about KWin, but I'm fairly sure it requires OpenGL as well.

[agd5f]

The tear-free code is more of a proof of concept than anything else. I doubt it'll actually get merged to master.

It basically inserts a stall in the command stream to wait until the vline trigger is past the active area of the display. The problem is you don't really want to stall the engine if you can avoid it, plus, depending how large your command stream is, you may not finish rendering by the time the crtc starts scanning again anyway. The real solution is compositing and pageflipping. You'd basically do all of your rendering to a different buffer than you are currently scanning and then insert a page flip at the end of the command stream. As soon as the rendering was done, the buffer pointers would flip and the crtc would scan out of the newly rendered buffer at the next retrace. That way you are never rendering and scanning out of the same buffer at the same time.

[panda84]

re: EXA and compositing, as I understand it full EXA is enough to support some compositors (eg. Metacity) but you need OpenGL for Compiz. Not sure about KWin, but I'm fairly sure it requires OpenGL as well.

KWin 4 supports both OpenGL and XRender acceleration (in fact it runs -- slowly -- also in my really old Trident 8MB shared through XAA).

[Uber]

The tear-free code is more of a proof of concept than anything else. I doubt it'll actually get merged to master.

It basically inserts a stall in the command stream to wait until the vline trigger is past the active area of the display. The problem is you don't really want to stall the engine if you can avoid it, plus, depending how large your command stream is, you may not finish rendering by the time the crtc starts scanning again anyway. The real solution is compositing and pageflipping. You'd basically do all of your rendering to a different buffer than you are currently scanning and then insert a page flip at the end of the command stream. As soon as the rendering was done, the buffer pointers would flip and the crtc would scan out of the newly rendered buffer at the next retrace. That way you are never rendering and scanning out of the same buffer at the same time.

I love to test this as I have been wrestling with the tear in ATI for 6 months not in my HTPC running Mythtv.

I have an ATI 2600 card and is running Ubuntu 8.04 and Mythtv.

I have 2 DVB cards that deliver SD(Mpeg2) and HD (1080I H.264)

What further packages do I need to build to test this driver, and any special xorg.conf setings I should have ?

I kill for XVMC or at least proper XV and non tear video.

Good work for showing of something to teat and maybe we all get rid of the crappy tearing on ATI cards.

[Uber]

I don't think any of the distros want to be totally dependent on proprietary drivers when they are being expected to provide a seamless user experience on a huge variety of hardware. By booting the open source driver out of box they have the ability to cherry-pick specific fixes which match the rest of their release, although I don't know how much of that is done with Ubuntu.

I think everyone just want the spechs to be known and an working driver. Bug will be fixed just like any other GPL package.

It's not like the proprietary driver have anything useful that an open implemntation would miss nor any more "bug free".

It's not rant, it's an good thing ATI open up the spechs and in some time this will help them compete with Nvidia.

ATI got loads of PR that would cost $$$ othervise.

[agd5f]

I love to test this as I have been wrestling with the tear in ATI for 6 months not in my HTPC running Mythtv.

I have an ATI 2600 card and is running Ubuntu 8.04 and Mythtv.

This code only affects r1xx-r5xx radeons as there is no acceleration code yet for r6xx chips like the 2600. We are working on initial code and documentation now.

[Uber]

This code only affects r1xx-r5xx radeons as there is no acceleration code yet for r6xx chips like the 2600. We are working on initial code and documentation now.

Doh!

Ok, I have a few other boxes in my lab I could build for testing and setup as Frontend to my Mythtv HTPC. (SocketA/Pentium4 etc)

I have a box with an pile of mix from ATI Rage -> Radeon 9800 cards,
anyone that would work better than others ? (AGP/PCI)

So, any quick words/links to what other packages I need to build before making your git version ?

Looking forward to the R600 code

The closed driver claims to have fixed the tearing, maybe I'm missing something in the xorg.conf..

[airlied]

I'm completely confused.

AFAIK *before* AMDTI disclosed details about their cards, there was one open source driver trying to support ATI cards through reverse engineering. Is this correct? Was this the xf86-video-ati driver?

AFAIK *after* AMDTI disclosed details abou their cards, xf86-video-radeonhd was likely to take over the open source ATI driver mantle and xf86-video-ati was in it's death throes.

What has changed? Why didn't xf86-video-ati die? What is the point in confusing end users with two open source drivers for (largely) the same hardware? Where is xf86-video-radeonhd at the moment?

When will ATI cards finally "just work", "out of the box", on most Linux distros?

I hear a lot of news about different developments here on Phoronix but I'm confused about the bigger picture context.

Yes you are ,

-ati was not in its death throes ever.. at the time AMD were working on opening specs, Alex, before joining AMD (using some work I'd started) had just redesigned -ati to use randr 1.2, this is why the release gap between 6.6.3 and 6.8.0 was so long.

-ati can't die, what would support all the other cards. -ati isn't all reverse engineered, large parts of it were from ATI before the r300, and a lot of the fixes for r300 came out of helpers in ATI. Only the PCI Express and 3D stuff was ever really reverse engineered.

In any case the future from Red Hat's POV is kernel modesetting, and really for us that will obsolete -radeonhd vs -ati. Currently radeonhd is porting accel code from radeon, with kernel modesetting removing everything but the accel code I don't see the reason to offer the same accel code in two packages.

Dave.