On Sun, Sep 17, 2006 at 11:46:23PM +0300, Heikki Lindholm wrote:
> > You didn't get rid of the CPU-burning Flip() calls, did you?  At least
> > on my system, DirectFB spends about 10% of the CPU cycles waiting for
> > MGA engine ready.  Adding a usleep(2000) right before the Flip() call
> > reduces the CPU load but risks dropping frames.  I believe it would be
> > much more efficient if the Flip() method blocked the thread until the
> > hardware is ready.  That would require some new ioctl() in the kernel.
> 
> I read your earlier comment about this on the list. I was curious to ask
> if you could elaborate on this a bit. I _very_ briefly looked at what
> the Flip call does, and the only wait I saw was the wait for vsync,
> which for matroxfb seems to be nicely handled by a waitqueue in the
> kernel.

No, in fact it is waiting for the current operation to finish.  If you
do Flip() immediately after initiating a large blit operation, the CPU
will busy-wait in mga_waitidle() until the operation has finished.

> I believe adding an usleep() is really artificial way of reducing cpu load
> and not really solving anything

It does reduce the CPU load reported by "top" by about 10 per cent,
in my case from around 60% to 50%.

I agree that it is not the right solution and it will probably make things
worse if the CPU is really tightly loaded.  I tried replacing the usleep()
calls with sched_yield(), and that really broke the timing.

On Sun, Sep 17, 2006 at 11:21:27PM +0200, Stefan Lucke wrote:

> Marko, I think you showed me a response from Ville regarding the ioctl
> issue. But unfortunatly I could not find this. 

I probably did not forward his reply to you, because it was written
in Finnish.  On June 28, he wrote that using an IRQ would help but that
it would require at least one more ioctl() to the kernel.

> Was the modification based on the ioctl calls from him at directfb list
> which were not committed ?

I haven't tried any kernel patches.

        Marko
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel

Reply via email to