ATI, when will we be able to watch a movie in Linux??!!

[nbi1]

Yep, older chips had hardware support in the overlay block for video buffer swapping on vblank. On 5xx and higher this has to be done in software, ie a completely different implementation, and the X/DRI framework is a bit weak in that area. Not sure if fglrx still supports overlay page-flipping on older chips though.

The open source drivers recently picked up a tear-free solution that kinda bypasses the framework, not sure yet if we can do something like that in fglrx.

I was going to suspend my plan to dump my 4850 in favor of a 9800 GTX+, but keep talking. You almost have me there.

nb1, tearing is not a "bug", it's the lack of a feature (syncing Xv output to vertical blank). Not something that testing is going to find since that is expected behavior at the moment.

In some other thread you must have said something completely absurd and gotten the impression that I agreed with it. So now you can feed me anything?

Playback artifacts are a "lack of a feature"?? "Expected behavior"?? If I didn't spend $160 on my 4850 this would actually be funny. But I'm not laughing.

I don't think that expecting trouble free playback on powerful modern HW is asking too much.

Did you work for the Soviet Ministry of Propaganda in a prior life?

[energyman]

have you even read his posts?

that tearing is a result of shortcomings of DRI and X. It will be solved in the future, but at the moment the only way to work around it, is to rip out everything and replace it (what nvidia did). But before you do the switch, do yourself a favour and look at nvnews - and then contemplate the following:
with nvidia you are completly dependent on them
with amd there are two (!) open source drivers in the work, and a closed source one - and all three will benefit a lot as soon as dri2 is out.

[bridgman]

Playback artifacts are a "lack of a feature"?? "Expected behavior"?? If I didn't spend $160 on my 4850 this would actually be funny. But I'm not laughing. I don't think that expecting trouble free playback on powerful modern HW is asking too much.

OK, I guess we need to agree on terminology. I was responding specifically to the question about why lack of sync-to-vblank in Xv was not caught in testing, and my response was that sync-to-vblank for Xv was not supported in the code (even if we all agree that this needs to change).

There are two kinds of testing -- one might be called "compliance to spec" while the other might be called "fitness for purpose". I was talking about the first one, in the sense that the X/DRI framework doesn't properly support sync-to-vblank (drm handles it for direct-rendered OpenGL but not for requests from the X server) and AFAIK *none* of the DRI drivers properly support sync-to-vblank on Xv today, with the exception of (a) GPUs which have hardware support for overlay page-flipping on vblank, and (b) some code recently added to the radeon driver which may also be applicable to fglrx.

This is one of the things which everyone agrees needs to change, but I don't think there's going to be a standard X solution until we make the compositor a standard part of the framework and start standardizing features *and* upstream flow control to apps.

Again, the main point here was that our regular QA testing is against the expected behaviour, and expected behaviour today includes tearing under certain conditions on Xv, just like all the other DRI drivers. From a "fitness for purpose" perspective this obviously needs to be addressed, but just saying "it's a bug and we can't ship any of the other improvements" doesn't help anyone.

The solution for syncing Xv playback to vblank will probably be one of :

- using the same approach that waas recently added to radeon; strictly speaking a hack in the sense that it blocks server activity while syncing, but possibly an acceptable one

- making a change to the X/DRI framework to perform delayed buffer copies on vblank (Intel is working on this one), or...

- the real solution, which is integrating a standard compositor into the framework and building sync-to-vblank capability around the compositor

- replacing DRI completely with proprietary code (NVidia), which we are trying to avoid if possible

Did you work for the Soviet Ministry of Propaganda in a prior life?

Nope, most recent gig was large scale warehouse automation, then before that I spent a lot of years designing graphics hardware and software. Then again, I recently moved about 60km outside Toronto which is turning out to be almost as cold as Moscow ;(

[oyvind]

If you don't use Compiz/similiar. then use OpenGL as video-output and enable VSync in CCC. It's a bit more heavy on the CPU, but you shouldn't experience any more tearing then.
If you use Compiz/similiar, there's currently no way to get rid of the tearing. But afaik that's the same with nVidia and Intel.

Actually, I'm able to watch tear-free videos in Compiz if I use fullscreen OpenGL output in mplayer with the latest Catalyst 9.1. Don't ask me why, but it works (yes, I unredirect fullscreen windows). However, XVideo[TexturedVideo], which IMO is the better solution, works like crap, also without Compiz now . ATI X1400.

Hoping for improvements to XVideo in Catalyst 9.2 ! How difficult can it be for AMD, the open source radeon driver does a fine job with XVideo ..

[mirak63]

Actually, I'm able to watch tear-free videos in Compiz if I use fullscreen OpenGL output in mplayer with the latest Catalyst 9.1. Don't ask me why, but it works (yes, I unredirect fullscreen windows). However, XVideo[TexturedVideo], which IMO is the better solution, works like crap, also without Compiz now . ATI X1400.

Hoping for improvements to XVideo in Catalyst 9.2 ! How difficult can it be for AMD, the open source radeon driver does a fine job with XVideo ..

for a divx yes, opengl will work but not for HD !!!

[oyvind]

for a divx yes, opengl will work but not for HD !!!

Ah, OK. I haven't entered the world of huge HD movies yet . I tested a 1920x1088 movie, and you are right, it isn't able to play it back at full speed with OpenGL output. Seems mplayer needs to use swscaler for som pixel format conversion.

[nbi1]

have you even read his posts?

All too often.

that tearing is a result of shortcomings of DRI and X.

Don't know about DRI's flaws, but how can it be a problem of X when no evidence of tearing existed for ancient video HW (as pointed out by Kano)?

It will be solved in the future, but at the moment the only way to work around it, is to rip out everything and replace it (what nvidia did).

So? What's your point? I don't care what happens under the hood, I just want something that works.

But before you do the switch, do yourself a favour and look at nvnews - and then contemplate the following:
with nvidia you are completly dependent on them
with amd there are two (!) open source drivers in the work, and a closed source one - and all three will benefit a lot as soon as dri2 is out.

And what fine open source drivers they are. The current radeonhd doesn't have accelerated 2D for the RV770.

Whether it's nVidia or ATI, in both cases one is dependent on them. What matters most is not promises of impending features, but who actually delivers (at least on the basics).

[bridgman]

Don't know about DRI's flaws, but how can it be a problem of X when no evidence of tearing existed for ancient video HW (as pointed out by Kano)?

The pre-5xx HW had dedicated hardware support for this, so no X support was required. Newer chips (and older chips running Textured Video rather than overlay) do require software support, and this is where the framework needs work.

And what fine open source drivers they are. The current radeonhd doesn't have accelerated 2D for the RV770.

We actually did the initial implementation and release of 6xx/7xx 2D and Xv acceleration on radeonhd, and the RV770 was the first chip to come up and work. The code has been publicly available for a couple of months (7 weeks, I guess) and now seems to be at the point where it's ready to merge into master.

[jonnycat26]

The pre-5xx HW had dedicated hardware support for this, so no X support was required. Newer chips (and older chips running Textured Video rather than overlay) do require software support, and this is where the framework needs work.

Okay, just one question. Totally unofficial, nobody's going to hold you to anything.

If I have an ATI card (4650, which is a 7xx based card), what is my best hope for watching a video with composite turned on?

[bridgman]

OK, this would be one of those "simple questions without a simple answer" I mentioned in another thread

If you are running with an XRender (EXA)-based compositor, are sensitive to tearing, and can live without accelerated 3D for a bit then the open drivers are probably your best bet. The tear-free Xv code in radeonhd was acting up a bit so *today* radeon might be a slightly safer bet although I think a fix for radeonhd tear-free just got pushed today as well. You would need latest drm and ddx driver code.

If you are using Compiz (which requires OpenGL) then you'll need to use fglrx.

In that case the best (but not totally satisfying) would be to use OpenGL, play the video full screen, and set the "Unredirect Fullscreen Windows" option in whichever position eliminates the flickering from the playback fighting the compositor.

If you need windowed video, then playback through Xv is your best bet; make sure your display is set to 60 Hz since anything else will result in more visible tearing.