On Fri, 21 Nov 2008 12:19:59 +0100 "Nicola Mfb" <[EMAIL PROTECTED]> babbled:
> 2008/11/20 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>
>
> > it's accelerated - but likely polling the command queue status as you have
> > no
> > interrupts thanks to the linux kernel's policy of not exporting interrupts
> > to
> > userspace, so you're stuck with a poll loop. i can't remember if glamo had
> > a
> > "i'm done" interrupt for the command queue or operations - i know it had
> > several interrupts it can generate (but as the kernel wouldnt allow
> > userspace
> > to make use of them i pretty much ignored them).
> >
>
> I'm not sure I understand completely, may you elaborate this?
> Profiling my loop:
> {
> switch foreground paint color
> draw a vertical line from 0,0 to 0,639
> XCopyArea to scroll the screen 1 pixel right
> XFlush
> usleep(40000) to have aproximately 25 fps
> }
> I got that:XCopyArea + XFlush are about 100 microseconds long, usleep is
> about 44000, and as the last is not cpu intensive this should results in a
> near 0% cpu busy. But as top reports 70% of cpu wasted by glamo (vmstat
> reports 25% user time and about 50% system time), I added after XFlush a
> call to XSync, and this reported another 40000 microseconds wasted while
> waiting for X server to complete the request. As top reports again 70% of
> busy cpu I suppose that during the XSync the main CPU is working and suppose
> this is not only due to protocol latency and other overhead, but the glamo
> driver is doing some other things while the gpu is blitting.
> Is this the interrupt problem you are referring to?
> And if this is true would be possible to write a workaround?
> You are right, 2d is accelerated but this is unuseful if the cpu has to be
> busy while the gpu is working!
XSync sends a request to x and waits for a reply - so your client app will stop
and wait until x replies. x will reply once it has completed all existing
requests - that means the XCopeArea. while your app is waiting xglamo is
waiting for the gfx chip to do the work - and likely its sitting in a loop
polling checking when the command is done.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
