[Nouveau] Syncing to vblank for interlaced video modes

Younes Manton younes.m at gmail.com
Tue Feb 9 10:21:44 PST 2010

On Tue, Feb 9, 2010 at 12:50 PM, Alistair Buxton <a.j.buxton at gmail.com> wrote:
> On 15 June 2009 14:14, Jamie Smith <hutts at internode.on.net> wrote:
>> Hi Again,
>> It seems I've triggered off much more discussion than I originally thought I would provoke.  I forgot to actually state what I was proposing to do, but it appears that people have worked it out.
>>> >> > On Sun, Jun 14, 2009 at 11:56:45PM +0100, Alistair Buxton wrote:
>>> >> >> Stupid question: Given the presence of a register which indicates the
>>> >> >> current field, why can't NVWaitVSync simply wait until the end of the
>>> >> >> second field, by doing whatever it does twice iff it is called during
>>> >> >> the first field?
>> Yes, this is what I'm proposing.  A server option that modifies the behaviour of the sync code so that if a) the option is set and b) the current video mode is interlaced, then wait until after the second field has been drawn before flipping pages/updating buffers etc.
> [snip debate about whether this is a good idea]
> I have been thinking about this problem recently and I have come to
> the conclusion that it isn't necessary to change the vblank interrupt
> frequency or add any special hooks to let the player know which field
> is being shown. No drivers changes should be needed at all. It only
> requires that players are more smart about how they display interlaced
> content to the screen.
> At the moment, every player I know of, when interlacing is disabled,
> just does simple weaving. This is bad as when you display it on an
> interlaced screen there is no way to know which field will get
> displayed first. But there is a better way. If, each time the player
> receives a vblank interrupt, it draws the next field into the display
> (ie updating every other line on the framebuffer, and leaving the
> other lines alone) then each field is in the framebuffer for 1 whole
> frame, and no matter which framebuffer field is currently shown, the
> next one will always contain the correct next field.
> Effectively it is weaving, but instead of weaving each frame's field
> pair, the frame rate is doubled by weaving every sequential field pair
> even if they belong to different frames. So, assuming lower-field
> first, it would produce frames composed like:
> (1L,nothing),(1L,1U),(2L,1U),(2L,2U),(3L,2U),(3L,3U)...
> Why it works is kind of hard to explain without a diagram so I have made one:
> http://al.robotfuzz.com/~al/nouveau/path7109.png
> Anyway, since no driver changes are needed, this is now offtopic. But
> does anyone know a player that can do what I am describing? Or maybe
> this method of playback has a special name I am not aware of?

The problem with that is that the player is typically not copying to
the actual frame buffer, or even the same buffer that was copied to in
previous frames. It's copying to some buffer that's not guaranteed to
contain anything specific, let alone the previously copied content.

More information about the Nouveau mailing list