[MPlayer-dev-eng] [PATCH] Improved DGA vertical retrace sync

[Stephen Davies]

On Tue, 24 Sep 2002, Arpi wrote:

> Hi,
> 
> > > yes, as mga cards don't need it at all, they can do buffer switching by
> > > hardware, without any help by driver or sw. just program the chip to switch
> > > to buffer N. at next vsync, and it will do that.
> > 
> > 
> > Hi,
> > 
> > Does the tdfxfb driver handle VSYNC?  I don't think so from looking at the
> > kernel tdfxfb.c and at vo_tdfxfb.c.  Or, have I missed something?
> > 
> 
> i don't think so, as the tdfxfb isn't really an overlay, but a bitmap scaler
> which support yuv format textures too.
> so, in case of tdfxfb, the scaled image is in the framebuffer, unlike mga
> where it's a ghost over the buffer not really rendered but scaled onthefly
> by DAC


I noticed in the X tdfx driver that there is a commented out command to
the card to "wait for vsync" in TDFXScreenToScreenYUVStretchBlit()

I might try uncommenting that.  Seeing its a command to the card processor
it shouldn't block the main processor.  Though I guess elsewhere there
are probably busy-waits for the card to get done which will result in
mplayer being blocked until vsync.

What will happen in mplayer if the flip_page blocks until the next vsync?

Steve