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

[Antonino Daplas <adaplas@pol.net>]

On Mon, 2002-12-09 at 19:21, Denis Oliver Kropp wrote:
> > 
> > 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.
> 
> Did you try sched_setscheduler (SCHED_RR) and
> setpriority (sched_get_priority_max()) ?
> 
Or just use 'nice'.

> I'm not sure if the process running during the interrupt occurs continues
> after the handler, but I think our process is the next to run after waking
> up.
> 
This one I'm not sure myself.  The top-half is where the actual
interrupt is handled.  To minimize the load in the hard irq handler, a
process can choose to do the main bulk of the work in the bottom-half
(sleep_on()/wake_up() and family) -- this is not required, you can
choose to do everything in the handler.  Top-halves will have the
highest priority, and will always be served, at the expense of the
bottom half.  So, if there are other processes that are still in queue
in the bottom-half (woken up by a previous top-half) when your process
wakes up from a top-half, it still has to wait. If you have the highest
priority though, you will be moved at the top of the queue.  

So, if a slow or CPU-intensive process is running concurrently with a
low-latency process, the low-latency process will suffer.  Think jerky
mouse movement and sound skips during disk activity. 

After that, the process can choose to continue to run (ie vsync_irq
patch) or just sleep again and wait for the next event (most character
drivers such as the mouse.)

Tony




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