Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)
Nicola Mfb
nicola.mfb at gmail.com
Fri Nov 21 12:19:59 CET 2008
2008/11/20 The Rasterman Carsten Haitzler <raster at rasterman.com>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20081121/0a5f08d0/attachment.htm
More information about the community
mailing list