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

[Reimar Döffinger]

On Tue, Mar 03, 2009 at 10:52:35AM -0800, Stephen Warren wrote:
> Reimar Döffinger wrote:
> > 
> > On Wed, Feb 25, 2009 at 01:59:22PM +0100, Reimar Döffinger wrote:
> > > On Wed, Feb 25, 2009 at 01:45:39PM +0100, Dan Oscarsson wrote:
> > > > On 2009-02-25 at 13:05 +0100 Reimar Döffinger wrote:
> > > > > According to my information, you are supposed to use the timestamps
> > > > > feature of the flip queue to solve this issue. I have not yet
> > > > > investigated that though, so I do not know if it is actually
> > > > > appropriate for MPlayer.
> > > >
> > > > It can probably be used in the sync-to-vsync handling i mplayer, but
> > > > will not solve this issue.
> > >
> > > As I understood it, it will automatically drop a frame if there is no
> > > vsync between the requested display time of that and the next frame, so
> > > it should solve the issue, but in a way that would allow VDPAU to have
> > > full control and e.g. use strategies to minimize jitter (which are
> > > easier to implement at driver level).
> > 
> > Tests reveal that you are right though. What concerns me is that in my
> > own attempt, vdp_presentation_queue_query_surface_status would not work
> > at all, surfaces would remain in queued state forever.
> > Maybe someone else can find out why with attached patch.
> 
> I just tested vdp_presentation_queue_query_surface_status, and it seems to
> work OK. I did see one problem with your patch; it was querying the surface
> status for next_surface, which isn't the surface being rendered to.

That is intentional, querying the one we just rendered to (and we
explicitly waited to become idle) would be a bit pointless.

> With
> the original patch code, the status is always VISIBLE for me, which isn't
> surprising, since the surface not being rendered too is expected to be
> VISIBLE.

Uh, why? After the patch there are 6 surfaces, if the next surface is
VISIBLE, there are 4 others that are still QUEUED....
Also, for me (unless I messed up my testing again) it was always QUEUED, too,
which would mean there were 5 QUEUED and one IDLE surface, which does
not really make sense...

> If I fix the patch to query status for the surface being rendered
> to (surface_num), then the status is always IDLE, which again makes sense,
> since video_to_output_surface always blocks until the surface is IDLE.

Well, as said that is not surprising. The question I wondered about is
why with 6 output surfaces all seem to be in use all the time. Normally
one should be VISIBLE and all others IDLE (and maybe one QUEUED), but
that's not at all what I saw - though it is of course possible I did
something stupid.