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

[vertigo]

@bridgman
I have a HD2600 XT AGP and video playback (even with Catalyst 9.1) is like CRAP. Seriously. CRAP.
I've been waiting for a year and a half to be able to watch a movie without tearing in Linux.
Is that really too much to ask??

NVIDIA supports HD playback in Linux but ATI doesn't even support SD.

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

[Zhick]

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.

[jonnycat26]

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.

Having just switched from nvidia to ATI (why, I wonder), I can assure you that you can watch a movie with a NV basaed card with composite enabled with no problem whatsoever.

Catalyst 9-x maybe?

[Zhick]

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.
Ok, just did some searching and found that this statement only is true for nVidia when VDPAU is used, otherwise it seems there's no tearing with nVidia+Compiz.

[albatorsk]

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.

It's a nice thought, but it's simply not feasible for HD video. I have an HD4870 and an Intel Q9450 (2.66GHz) and OpenGL output is lagging behind the audio when playing 1080i/p. With Xvideo it's fine, but the tearing makes it unwatchable.

[mirak63]

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.

this solution is useless with HD movies

I was able to watch fullhd movies with a 6600GT, now with a hd4850 I just can't

and it's now 6 months I run windows instead of linux, because of ATI.

to ATI : you don't say you support linux at the moment the video card is out if you can't even support video playback

[mirak63]

It's a nice thought, but it's simply not feasible for HD video. I have an HD4870 and an Intel Q9450 (2.66GHz) and OpenGL output is lagging behind the audio when playing 1080i/p. With Xvideo it's fine, but the tearing makes it unwatchable.

this issue should have been the top priority

[vertigo]

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.

Thanks. It works with OpenGL.
For the moment, I guess I need to turn the desktop effects off when watching a movie and turn them back on after that. I cannot work in KDE 4.2 without desktop effects because even moving a window is waaaay too much for this driver.
I wonder when HD playback will be possible..

[energyman]

just don't use compiz.

I am watching movies just fine - in kde.

[karthikrg]

wait for OSS support.. it should soon be coming for R600/700 3D.. then you can use compiz to your heart's content without videos tearing.. i too waited (without any use) for ati to fix it on my r520.. but have been using the open source radeon driver once it started supporting my card

[Kjella]

Ok, just did some searching and found that this statement only is true for nVidia when VDPAU is used, otherwise it seems there's no tearing with nVidia+Compiz.

And apparently there's a small patch (haven't tried it) to make tearing on VDPAU+compiz go away too:

http://forum.compiz-fusion.org/showthread.php?t=10764

[albatorsk]

just don't use compiz.

I am watching movies just fine - in kde.

Disabling Compiz doesn't fix the tearing.

[nbi1]

Disabling Compiz doesn't fix the tearing.

I can confirm that as I've never used Compiz (in fact I don't even know what it is :D).

The tearing in 9.1 even seems worse than in 8.12.

No matter how you slice it these drivers don't seem to be undergoing any serious testing before ATI makes them available.

[bridgman]

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.

[Kano]

Haha, it worked with older chips ;)

[bridgman]

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.

[albatorsk]

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.

So, basically what you're saying is that we may never get tear-free video playback with fglrx?

[bridgman]

Nope, I'm just saying that there's more to it than "fixing a bug" :D

[jonnycat26]

So, basically what you're saying is that we may never get tear-free video playback with fglrx?

At the very least, it isn't coming in Catalyst 9-2.

[RealNC]

Ain't this just great? :D

[dungeon]

Yes it is!:D:p

[vertigo]

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 doesn't work now and it won't work in the foreseeable future.
Great news!
Thanks!

[bridgman]

I doesn't work now and it won't work in the foreseeable future.
Great news!
Thanks!

Well, if you want to make up your own news and be disappointed by it I can't really stop you.

That is, however, *not* what I said.

[jonnycat26]

Well, if you want to make up your own news and be disappointed by it I can't really stop you.

That is, however, *not* what I said.

I know it's not your fault, and I really appreciate having someone in the know who takes the time to post here..

But if we could have some or *any* idea as to what's being worked on and what's a priority, it'd really mollify a lot of us.

[bridgman]

Nobody in the business pre-announces software features, and I don't really think we are likely to start doing that ourselves.

That said, it's a pretty fair bet that your priorities are the same as ours, with the caveat that most of our Linux business comes from the commercial workstation market so our priorities will continue to be a mix of consumer and commercial expectations.

That doesn't mean that consumer wants will be ignored (far from it), just that the progress may not always be as fast as you would expect from the resources we are committing to Linux. When you see improvements in areas that you don't give a rat's a** about, like Crossfire or the ability to run accelerated 3D on 4 screens, remember that those features *are* important to other Linux customers even if they're not something you care about.

Unless you're looking at a few specific issues (eg running fglrx with bleeding edge distros and unreleased kernel & xorg versions, or duplicating NVidia driver *internals* so that Wine devs only have to code for one GPU) our plan is to continue making improvements in the areas that users are asking about the most.

[jonnycat26]

Nobody in the business pre-announces software features, and I don't really think we are likely to start doing that ourselves.


Not to be an ass, but aren't you really in the hardware business? As I see it, you only write drivers so that the hardware you sell works. Given that fact, wouldn't it make some sense to tell us what we can expect in the next few months to year?

[bridgman]

Sure, in the sense that we *sell* hardware and *license* software, but the software and hardware engineering efforts are not that far apart in scale, and at various times most of the GPU vendors have spent equal amounts on SW and HW engineering.

We are in the product business, and most of the visible face of the product is software.

Modern GPUs have evolved into highly parallel floating point engines with a few specialized functions (eg texture filtering and triangle rasterization) so the "system functionality" (ie what most of the competition is about) is almost entirely defined by software.

The "new hardware features" are really boring -- all of the "new features" are in software. The days of software just exposing the underlying hardware capabilities are long gone.

[jonnycat26]

Sure, in the sense that we *sell* hardware and *license* software, but the software and hardware engineering efforts are not that far apart in scale, and at various times most of the GPU vendors have spent equal amounts on SW and HW engineering.


But... but... if people knew (specifically linux users) that you were planning on fixing things like, dunno, the opengl flickering with composite enabled, maybe they'd buy an ATI card instead of a NVidia. Maybe I wouldn't throw mine down a sewer.

Just saying. :)

[bridgman]

I do understand that, and it's a strong argument for providing pre-release info, but we also don't want to get stuck in a situation where people are making purchase decisions based on future promises which for some reason we can't deliver. We have to sell based on what we are shipping today, combined with your reasonable expectations for the future based on the progress you have seen so far.

Right now only one released driver supports OpenGL under Compiz and that driver does it by replacing DRI with proprietary code. The X/DRI community is planning to move from "compositing off by default" to "compositing on by default" over the next year; we expect to be part of that transition.

[Redeeman]

in that case you might want to make it somewhat more apparant to the linux users what to expect, after having huge giant humongos articles on phoronix, displaying tux and ati logos, saying same day support and all sorts of stuff(i realize this isnt really ati/amd doing those articles), you may want to slap a huge giant notice on your linux page saying:
"Dear customer, while we do provide a blob for linux, which can(maybe, if you happen to have a lucky motherboard) drive the card, lots of features are probably not there, or broken. For instance, you may experience X not starting, video will probably be useless for you, and we dont have ANY idea(that we will tell you about though) when this might come."

Btw, now that i got you here, any progress on getting the weird half-wrong message removed from the 64bit driver download page?
http://www.phoronix.com/forums/showthread.php?t=10868

[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? :D

[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? :D

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. :rolleyes:


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 :D

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.

[jonnycat26]

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



I'm using KDE4 and the desktop effects therein, so would I still need fglrx?

And when I play in a window, I get weird distortions when any sort of on screen display is overlayed into the video (ex, volume notfications or playback state notifications).

[bridgman]

KDE4 (KWin) can use either XRender or OpenGL; it seems to work pretty well with the current open drivers if you pick XRender.

[jonnycat26]

KDE4 (KWin) can use either XRender or OpenGL; it seems to work pretty well with the current open drivers if you pick XRender.


But then games (UT2004 and World Of Goo) would pretty much not play at all, correct?

[bridgman]

Correct. If you are also gaming on the system then best bet is probably fglrx, OpenGL output, fullscreen for now.

I haven't tried Xv on the 9.2 Cat release but if you run 60Hz refresh it's probably worth trying as well. With Xv you don't get sync-to-vblank but you also should be able to run windowed under an OpenGL compositor without flicker.

[Blacksmith]

Bit of a question here....
I have a 4870 I get tearing in video play back that looks exactly like an analog tv with serious sink problems but only with xine. mplayer and ogle are perfect. Is this the dreaded Vsync problem mentioned here? Do not regard this as serious just interested! ;-)
Version of FGLRX not an issue here has done it for a few different versions.

[bridgman]

The Xv spec doesn't actually mention syncing to display refresh at all; I think there may be attributes which can be passed to the driver but from what I can see most of the drivers which do implement sync-to-vblank impose it without being asked by the application.

My guess is that some players implement their own sync-to-refresh logic while others rely on the driver invisibly implementing it, but that is only a guess. I'm not sure if the attributes passed to the driver are standardized or not, but at first glance there doesn't seem to be any standardization.

This is all kind of academic anyways; implementing vsync in the Xv and GL drivers stops making sense as soon as you run under a compositor (except to the extent that the compositor uses OpenGL to display the composited screen); we really need to either develop a standard way of managing flow control from apps to screen or, if one already exists, make sure everyone knows about it :D

[mirak63]

I didn't tried for a few month, but my tearing happened on mplayer on ubuntu intrepid

[Blacksmith]

Thanks for the reply to my question bridgman, sounds right, been very helpful. I have been using linux since kernel 0.96d (mid 1993) and I always thought the it is amazing how WELL it works when everyone is pulling in different directions.

[nico342]

I hope so much that AMD fix his driver as soon as possible for everybody. A least I'm able to watch movie on my ATI 2400 HD PCI... / with Intel Atom but I got a annoying video tearing problem. :mad: , specially with video upscaling. Is there any one with good HD video playback on ATI .... with Linux lol.

Hope with next Catalyst realease. :)

[Kano]

HD video with ATI, I think you live in a parallel universe ;)