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! Regards Nicola
_______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community