Is there a back to basics solution to tearing?

[proudclod]

Hello there,
I'm running a pretty standard (fully-updated from their own repos) install of Ubuntu 8.04, on my new Q6600/4GB/Radeon 4850 system. I've installed the Catalyst 8.8 drivers (without any troubles - the last time I did this was back in 2004, when fglrx seemed to require kernel patches and other hoodoo) simply because neither radeon or radeonhd worked out of the box with the 4850.

My problem is simple - I get tearing on videos and on the edges of windows while moving them horizontally. This is most marked when Compiz is on; particularly with videos which flash uncontrollably and render everything unwatchable. But even with Compiz off, the window-edges still tear, and videos still exhibit vsync issues upon fast panning.

Now the thing is, I don't really care about fancy visual effects, I don't need Compiz, I don't need the closed source drivers or 3D acceleration. I just want a computer which has a display that I can write my thesis on without making me feel ill, and maybe watch a DVD or two upon. Ubuntu is so nearly there, everything else works flawlessly, and I really don't want to have to go back to Windows - crashes killing or corrupting my work is why I switched to Linux four years ago.

So the questions are:
1. Is there anything I can do with my current "fglrx" setup? I fear not - I've tried pretty much everything that two days of googling can turn up, and it looks as though ATI's current vblank interpretation is just fundamentally broken and I should give up, but I thought I'd ask anyway.

2. So if we accept that, would the latest open source "ati" drivers help? I've heard that through AtomBIOS this produces fairly decent 2D and Xvideo acceleration. If the answer to this is yes, then how would I go about getting and installing these on Ubuntu 8.04? (I know ideally I'd wait for 8.10 which includes these drivers, but I need to start writing in two weeks). I've seen the general tutorial stickied in this forum, but which steps (drivers, DRM modules etc.) would I need for my simple wishes - working 2D and Xvideo, but no compiz or accelerated 3D necessary.

3. Should I jack this all in, and ask to swap my 4850 for my (Windows-gamer) younger brother's 8800GT? Is the NVidia implementation of vsync actually as functional as I'm lead to believe?

Many thanks for your time,
Tom

[Redeeman]

vsync on nvidia cards which has overlay works. i dont have a new nvidia card, but textured xv does NOT vsync properly on my quadro.. ofcourse there are also bugs with nvidias overlay stuff.. but that is something i only see on my quadro, not on other nvidias.. and only with high resolution 1080p video.

[bridgman]

What is the current thinking about rendering through OpenGL with sync-to-vblank enabled on OpenGL ? Is that working for people ?

[proudclod]

By rendering through OpenGL, do you mean setting gstreamer/mplayer/vlc/whatever to use an opengl output rather than Xv, then forcing vsync in the ATI Control Panel?

I tried that and it didn't solve the misbehaving-overlay type behaviour in video playback - and of course, surely it would do nothing to solve the edge-tearing I'm seeing on Windows?

(Apologies if I've got the wrong end of the stick entirely)

[bridgman]

Yes. Not sure what you mean by "misbehaving-overlay type behavior", but if the tearing you are seeing is caused by lack of sync-to-vblank then playing through OpenGL with sync enabled should eliminate the tearing *if* the player app uses OpenGL in a way that lets the sync-to-vblank be effective. That's the part I'm not sure about.

[proudclod]

Yes. Not sure what you mean by "misbehaving-overlay type behavior", but if the tearing you are seeing is caused by lack of sync-to-vblank then playing through OpenGL with sync enabled should eliminate the tearing *if* the player app uses OpenGL in a way that lets the sync-to-vblank be effective. That's the part I'm not sure about.

Hi bridgman, I appreciate the efforts of you all on the ATI/AMD team.

With Compiz on, the video under OpenGL+sync-to-vblank flickers just as it did when using Xvideo. Indeed, the video seems to hover above any other open window.
With Compiz off, it seems to fix tearing in the video itself. This is progress, certainly. But (without wanting to sound ungracious) it doesn't fix the bigger issue - there's still tearing when I move that video window around on the screen, and there are certain other sources (for example, BBC iPlayer videos in Flash Player, which makes up a large proportion of viewing in the UK) which cannot be easily redirected to a different output filter.

I suppose the question is, failing any possible tweaks to fglrx, would xserver-xorg-video-ati do anything to help this?

[bridgman]

There are actually two completely separate issues here.

The flickering under Compiz is happening because both Compiz and the Xv driver are trying to write into the same area on the screen. "Misbehaving overlay-type behaviour" is actually a pretty good name for it. Once we get 6xx/7xx acceleration added to the open source drivers (which should be fairly soon, at least for video acceleration) that should take care of the Compiz flickering.

There is an "unredirect fullscreen windows" option in Compiz which will help with fullscreen video but I realize most folks like to play video in a window.

The tearing when you are not running Compiz but dragging a window is happening because the drawing ops which *move* the window (via the X driver) are not synced to vblank even if the drawing of video *into* the window is synced properly via the OpenGL driver. That will take a bit longer because the mechanism for handling sync-to-vblank for anything other than OpenGL is kinda being redesigned now and my guess is that it will show up around the same time as DRI2 (ie pretty soon).

[proudclod]

Ah, that makes sense completely - it's rather a shame, as I gather DRI2 has been written out of the upcoming Xorg release until they sort the memory management issues, so I figure it'll be at least 6 months until we can expect a fix?

In that case, I'll probably try an NVidia card for now (at least to see if it fixes the issue), then try my Radeon again during the academic vacation (June 2009). I was possibly planning to buy another 4850 and Crossfire them then, anyway. Hopefully the driver and X scene will look a little different in nine months.

Best,
Tom

[bridgman]

Kristian's new DRI2 code is starting to go into the tree now, so I don't think the wait will be as much as 6 months, at least for the more aggressive distros.

[NaterGator]

AKA switch to gentoo :)

Glad to hear DRI2 and memory management are coming along nicely. I'm waiting/excited to check out the new code.

[jeffro-tull]

AKA switch to gentoo

eh?

The stuff in "arch" is fairly long in the tooth. The stuff in "~arch" is maybe on par with what Ubuntu and OpenSUSE shoved out of their last release.

I know about layman... I'm running the x11 overlay on my laptop (X1300 video card, if that doesn't explain it). Maybe I'm doing something wrong, but it doesn't seem like there's been that much activity with that overlay. I sync my portage tree and the overlay every few days, and x11 has told me I've been up to date for the past three weeks.


Or did you just mean that with a Gentoo system, most everything you'd need for a build environment is already there from the word "Go"?

[krazy]

Once we get 6xx/7xx acceleration added to the open source drivers (which should be fairly soon, at least for video acceleration) that should take care of the Compiz flickering.
Does 'fairly soon' apply to both ati and radeonhd drivers?

[TechMage89]

3d Acceleration is independent of the xorg driver, because that's in mesa, where there's only one driver for r500+ cards.

The Xv implementation will probably be added to both the xorg drivers fairly quickly, since they share a lot of code.

[krazy]

3d Acceleration is independent of the xorg driver, because that's in mesa, where there's only one driver for r500+ cards.

The Xv implementation will probably be added to both the xorg drivers fairly quickly, since they share a lot of code.
Thanks for the explanation. So does this mean that if I've got a r500+ card, it is largely irrelevant which driver I use for 3d gaming?

[hobbes]

3d Acceleration is independent of the xorg driver, because that's in mesa, where there's only one driver for r500+ cards.

The Xv implementation will probably be added to both the xorg drivers fairly quickly, since they share a lot of code.

So, just make things clear for now on (at least for me!)

There is NO hardware accelerated video playback support on the xf86-ati (radeon), right?

[agd5f]

So, just make things clear for now on (at least for me!)

There is NO hardware accelerated video playback support on the xf86-ati (radeon), right?

xf86-video-ati supports hw accelerated video playback (colorspace conversion and scaling) for r1xx-r5xx cards. Only r6xx lacks acceleration at the moment.

[Zhick]

. I sync my portage tree and the overlay every few days, and x11 has told me I've been up to date for the past three weeks.
The ebuilds with version number 9999 are straight from git. When using this ebuilds you won't see any updates n a simple emerge -avuD world. This also wouldn't make any sense since there is pretty much always a change (except you update multiple times a day). Simply re-emerge the packages with version 9999 to stay up to date.

[TechMage89]

I was referring to Xv for r600+. Both drivers have support for Xv through r500.

[bridgman]

For clarification :

- there are two parts to video acceleration, decode and render
- render is usually the most time consuming; Xv is the API for render acceleration, both open source and fglrx implement Xv acceleration
- open source drivers do not have video render acceleration for r6xx/7xx yet but getting close

- decode is not accelerated on either driver today
- decode has three main parts: IDCT, MC, "everything else"
- MC is typically most CPU intensive decode task; R5xx accel docs include enough info to write MC acceleration AFAIK

[hobbes]

For clarification :

- there are two parts to video acceleration, decode and render
- render is usually the most time consuming; Xv is the API for render acceleration, both open source and fglrx implement Xv acceleration
- open source drivers do not have video render acceleration for r6xx/7xx yet but getting close

- decode is not accelerated on either driver today
- decode has three main parts: IDCT, MC, "everything else"
- MC is typically most CPU intensive decode task; R5xx accel docs include enough info to write MC acceleration AFAIK

Thank you for clearing that out.

Perhaps, that explains why some x264 video (1280x720p, real ones) drop some frames and lags on some "actions scenes" or "too wide, too many detailed background scenes"

I can precisely point out this scene of Terminator (1984).

uploaded sample: http://rapidshare.com/files/142752531/T1.Sample.avi

(1920x720p, x264/AC3, 03:10 min, 195,5 MB) Sorry for the file size, but it is all in there.

I can not play this particular action scene without jumping too many frames or totally losing A/V sync.

Totem (gstreamer or xine), mplayer or vlc can't do it.

It is the toughest scene I've encountered so far.

Things get messy after the explosion scene. I took the liberty to edit leaving some seconds before, just to preserve most of the integrity of it on some "unknown editing issue"

Maybe this particular sample would be a great asset to fully optimizing HD playback on R500. I would hope so.

It can't also be played on Catalyst. At least version 8.6, the last one I have used before switching - for good, I hope - to radeon open source driver.

My system can playback a 720p real file. At least on theory.

Hardware:

Sapphire AGP X1600 pro + Pentium D + 2GB RAM + Debian SID + Experimental packages. The same occurred using Intrepid.

Software:

xserver-xorg-core: 2:1.4.99.906-2
libgl1-mesa-dri: 7.1-1
xserver-xorg-video-radeon: 1:6.9.0+git20080826.a3cc1d7a-1

PS: Perhaps a creation of a Thread with some uploaded 720p samples could lead to some new HD playback improvements on the future. What do you guys think of that?

[whatever]

Perhaps, that explains why some x264 video (1280x720p, real ones) drop some frames and lags on some "actions scenes" or "too wide, too many detailed background scenes"
there won't be gpu accelerated h264 decoding for linux in near future. even if there was support in the driver - the players couldn't use it yet.
to lower cpu usage i suggest you get the latest mplayer from svn and compile it yourself. additionally you can use "-lavdopts skiploopfiler=all" to disable h264's deblocking, this helps a lot for me.

btw: with skiploopfilter and current mplayer your sample plays fine here on my old athlonxp 2600+ with radeon 9700. ~70% cpu usage.