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

Dan Oscarsson Dan.Oscarsson at tietoenator.com
Wed Mar 4 08:32:55 CET 2009


On 2009-03-03 at 20:21 +0100 Reimar Döffinger wrote:
> > > 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 some testing yesterday and so far it looks like queued surfaces in
the presentation queue do not move forward to be displayed. I had nearly
the same when I tried with my patches when using the 180.22 driver. Then
it looked like if you did not do "wait for idle on presentation queue",
the queue never moved forward. My patches worked with 180.29. Did not
get 180.35 working so have not tried with it. I would expect the
presentation queue to do its processing independently of what mplayer is
doing - it looks like it does not do this in some cases.

This looks like a bug for NVIDIA to check.

I will, if I have time, later today do some more testing with your and
mine patches and see if I can see what differs.

I am not sure your way is better then mine, though.
With your patches you fill presentation queue with surfaces, but the
last free is not entered when all other is in use. Instead it is reused
by draw_image for next frame. In my patches, all surfaces are put into
the queue and draw_image skips processing when no free surface is
available. Also, with my patches the check for free surface is delayed
until it is needed (in draw_image) instead of at "flip page" which gives
presentation queue more time to get free a surface.

   Dan




More information about the MPlayer-dev-eng mailing list