Re: Vertical retrace interrupts?

On Fri, 2003-01-31 at 08:16, Fredrik Noring wrote:

Hi Antonino,

fre 2003-01-31 klockan 00.22 skrev Antonino Daplas:

quoted

However, at least 3 people have mailed me that they are using their
somewhat old pc as a set top box with mplayer, DirectFB and i810fb. No
X.  The image instability is noticeable because they are driving
big-screen TV's, especially because DirecFB is double-buffered, with
triple-buffering in the TODO list.

I don't think vertical retrace synchronisation is strictly necessary 
for excellent video playback on low-grade systems. Reason is that I
believe most graphics cards delay the flip automatically in hardware
using shadow registers which load the real registers during retrace.

This is true if you have triple, or more, buffers -- (buffer currently
being displayed, buffer waiting to be displayed, and buffer being
decoded to) and if the display refresh rate is faster than the video
frame frate.  In this case, you can just simply rely on the hardware
doing the actual buffer flip during vblank since you are guaranteed that
the next frame will not arrive until at least one vertical retrace
later.

With double buffers, you still need to synchronize with the retrace
signal, otherwise the video decoder will write to the buffer currently
being displayed (because the actual flip was delayed by the hardware). 
Polling for the VGA registers will be enough in most cases, but will not
work correctly with some hardware.
 

The software only needs to flip the buffers with approximately the same
frequency, and it'll work fine.

Right, the software will flip the buffers at the correct frequency.
However, decoding will occur immediately after returning from the flip
command.

I've sent a few patches to the Xine (video player) developers to improve
the frame buffer driver and player. The new driver allocates as many
buffers as possible natively in video RAM. Thus, with a 16 MB TNT card
you'll get about 9 buffers at 768x576x32 (PAL DVD) resolution. That
should give the driver plenty of margins to deal with occasional
scheduling problems etc. because the only essential thing it needs to
do meanwhile is flipping buffers using the FBIOPAN_DISPLAY ioctl. This
can be done with the regular Linux kernel frame buffer drivers.

Ahh, you have a lot of buffers here, so vretrace synchronization is not
a problem.  I was referring to DirectFB which is only double-buffered. 

Tony



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com