[MPlayer-dev-eng] [PATCH]: reduce vsync wait in VDPAU

[Dan Oscarsson]

On 2009-02-25 at 17:16 +0200 Uoti Urpala wrote:
> On Wed, 2009-02-25 at 11:09 +0100, Dan Oscarsson wrote:
> > In vdpau, the draw routine wait for an output surface to be idle. With
> > just two output surfaces, vdpau will have one displayed and one waiting
> > to be displayed. At next vsync, the displayed get idle and can be
> > reused, and the waiting one gets displayed.
> 
> This doesn't match what I see with vo_vdpau (using driver version
> 180.22). Playing with "-vo vdpau -benchmark -nosound" I get higher
> framerates than monitor refresh rate (with both hardware and software
> decoding). This is unlike for example -vo gl which IS limited to monitor
> refresh rate at default settings. An older version of VDPAU may have
> differed in that regard, I don't remember for sure. Are you sure the
> behavior differs on your machine? If so, what driver version do you use?
> Do you have composite enabled? Any other settings which could possibly
> affect it?

I am using 180.29. And composite is disabled as vdpau do not sync on
vsync when composite is enabled. Instead you get tearing as images are
blitted to the screen at any time.

Before I upgraded to 180.29 I used 180.22 and then it looked like you
had to do the call on the presentation queue that waited for a vsync so
that a surface got idle, because otherwise it was not displayed. With
180.29 it worked as I expected (the queue worked and displayed images
without mplayer waiting on it so mplayer could do other things).

   Dan