[MPlayer-users] Any way to get Xv playback without tearing on fglrx?

[Vladimir Mosgalin]

Hi Nikos Chantziaras!

 On 2008.07.24 at 05:05:24 +0300, Nikos Chantziaras wrote next:

> OK, I've completely upgraded X, kernel 2.6.26 (needed for r500 DRM) and 
> xf86-video-ati 6.9.0 plus all needed dependencies (Mesa and stuff, 
> including dri2).  Fortunately, the stuff is already in Gentoo's repo 
> (marked as testing/unstable) so installation was automatic.

lucky you ;)

> I get OK 3D support now and 2D is orders of magnitude faster than fglrx. 
>   I guess that's win :)
> 
> Bad news, still tearing with videos :P  xvinfo now says:

Yep. No one promised no tearing ;)

> gl doesn't work at all.  Currupted screen and mplayer says:
> 
>    do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working
>    correctly.
>    Try adjusting the vblank_mode configuration parameter.

Um.. Maybe Reimar would be able to help you with that, if you provide
more details? Using mplayer -vo gl with opensource driver is really a
way to go. I don't want to go back to xv with all its problems, like
low-resolution subs (very ugly when fancy fonts in ass/ssa are used) and
monochrome osd. Some vobsubs are basically unwatchable with monochrome
osd, colored osd with -vo gl fixes that.

> So I guess the open source driver is better in other areas, but still as 
> crappy as fglrx in video tearing?  But I'll try tweaking some settings more.

That won't help. Tear-free acceleration isn't in the main branch yet.
You may try vsync-accel branch though, read
http://www.botchco.com/agd5f/?p=30

please not that this is considered strictly an experiment, that's
what agd5f says about it:

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

-- 

Vladimir