[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga

[Antonino Daplas <adaplas@pol.net>]

On Sun, 2002-12-08 at 22:52,
a40e8119bbddbe7b3d281db117f19b32@interlinx.bc.ca wrote:
> On Mon, Dec 09, 2002 at 01:01:15AM +0500, Antonino Daplas wrote:
> > 
> > Neither am I.  You probably know more about matrox hardware than I.
> 
> Doubt it very much.  :-)  Ville on the other hand...
> 
> > Ahh, okay then.  So the matrox hardware automatically displays an
> > interlaced data stream to an interlaced display device without
> > additional processing.
> 
> That is my impression.  Check out this thread:
> 
> http://www.directfb.org/mailinglists/directfb-dev/2002/07-2002/msg00099.html
> 
> > >From what I know about this kind of hardware (which is not much), is
> > that they are more sensitive to the overall system latency rather than
> > CPU power.  You probably know the latency condition of linux, it's not
> > just the high latency, but the irregularity of it.  You can easily
> > compensate for high latency as long as you know it's constant, but a
> > high latency range from a few milliseconds to a few hundred milliseconds
> > is a killer.
> 
> I seriously doubt my PVR is experiencing several hundred millisecond
> latencies.  I could always be wrong, but I am in doubt.
> 
Unless you have a low-latency patch, or using RT-linux, you can never
know.  Latency depends on so many things that it actually led to a
rewrite of the linux scheduler for 2.5 and inclusion of kernel
preemption.  Latency killers:

console
framebuffer 
disk activity
and some more

> > It's the way how each field is displayed by typical hardware.  This may
> > not be true with matrox hardware, but with interlaced data, the display
> > of field 1 starts almost immediately after flipping the frame. The
> > display of field 2, on the other hand, occurs at a fixed interval
> > independent of the frame rate. The interval is determined by the
> > system.  For a PAL system:  25fps, 40ms/frame, 20ms/field.  So field 2
> > is displayed 20ms after field 1 and whether the frame rate is decreased
> > or increased, field 2 will always occur 20ms after field 1.
> 
> How can the framerate be increased or decreased with fixed framerate
> hardware like a television.  The only way to do that is to duplicate
> or eliminate frames as necessary to maintain the constant output
> framerate.
> 

This was just an example to say that field2 will be shown at a fixed
interval after the arrival of field1, whatever the frame interval is. 
The change of frame interval may be due to delays in arrival of the
signal to the process, or by simply unthrottling the frame rate itself
.
 is where latency comes in to play.  Assuming that during waiting
> > for vsync for Frame0, the signal arrived 20ms too late.
> 
> You mean the interrupt?  The signal will always arrive at the right
> time.  The kernel may not deliver the interrupt for some time after
> the signal arrives however.
> 
Yes, the time interval from the arrival of the interrupt signal, waking
up the process, returning from the ioctl call, to processing the
registers.  That was what I meant.

Sleeping while waiting for an interrupt to arrive is very nice because
it gives the CPU to another process.  Very good for systems where CPU
power and thoroughput is important.  But this is not appropriate if the
process needs to get the signal immediately, or at least timely, manner.
The problem with this is during the wake_up().  Whether the process
wakes up now or a few hundred milliseconds later depends on so many
factors which the process nor the kernel can control. IE.  If at the
time of waking up, the current process using the CPU was not a nice
player and it won't give back the cpu to the kernel, you get delayed. 
If there are a lot of tasks waiting to wake up ahead of you, you get
delayed more.  And if each of these tasks waiting ahead of you awakes,
each will take a few more precious CPU cycles to process what it was
sleeping for, and you get delayed more and more.  And there is nothing
the kernel can do, because it cannot preempt. 

The worst part is that that each time you sleep, the time you actually
wake up will not be constant. It's actually better to have high, but
regularly timed latency, than relatively small but irregularly timed
latency. It's easy to compensate when latency is a known constant.

A lot of the latency problems are being solved in linux-2.5 (O(1)
scheduler, preemption, workqueues, CPU affinity, punishing CPU hoggers,
rewarding nice players, etc)

So, for things that are sensitive to latencies, you're better of polling
the registers directly, even just for testing purposes.  Athough it
increases CPU usage a lot, it will factor out the latency part.

> > Frame0Field1
> > therefore gets displayed at t20ms, and Frame0Field2, at t20ms+20ms = 
> > t40ms.  Next, you wait for vsync for Frame1, but this time it gets
> > delayed by only 5ms.  So Frame1Field1 gets displayed at t45ms.  However
> > Frame0Field2 is still being displayed by the hardware, and this can
> > cause visual artifacts.
> 
> I don't think so.  It is my understanding that the process is to load
> frames into the display buffer prior to the vsync, as early as you can
> in fact.  You then tell the card where the image is.  Once this is
> done, processing is done until the vsync interrupt because the
> hardware will take care to change to the frame you just loaded during
> the vblank.  The only way you could lose is that if you take longer
> than two fields to load up the next frame.  But MPlayer detects this a
> drops frames if I am not mistaken.
> 
The above is partly my point in the other thread.  Do you program the
registers before or after waiting for vsync?  Because if you do it
after, then that is another contributor to latency.

My whole point in a nutshell:

if thoroughput/bandwidth is important, sleeping on an interrupt is
preferable.  If latency is more important, directly polling the
registers is preferable.  Rule out the possibilites that can be
eliminated easily first.  Test for latency, then for bandwidth, and
compare the results.  If there is no change, you can probably start
looking somewhere else, such as a bug in the code.  

Tony





-- 
Info:  To unsubscribe send a mail to listar@directfb.org with 
"unsubscribe directfb-dev" as subject.