2008/11/20 The Rasterman Carsten Haitzler <span dir="ltr"><<a href="mailto:raster@rasterman.com" target="_blank">raster@rasterman.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>it's accelerated - but likely polling the command queue status as you have no<br></div>
interrupts thanks to the linux kernel's policy of not exporting interrupts to<br>
userspace, so you're stuck with a poll loop. i can't remember if glamo had a<br>
"i'm done" interrupt for the command queue or operations - i know it had<br>
several interrupts it can generate (but as the kernel wouldnt allow userspace<br>
to make use of them i pretty much ignored them).<br></blockquote></div><br>I'm not sure I understand completely, may you elaborate this?<br>Profiling my loop:<br> {<br> switch foreground paint color<br> draw a vertical line from 0,0 to 0,639<br>
XCopyArea to scroll the screen 1 pixel right<br> XFlush<br> usleep(40000) to have aproximately 25 fps<br>}<br>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.<br>
Is this the interrupt problem you are referring to?<br>And if this is true would be possible to write a workaround?<br>You are right, 2d is accelerated but this is unuseful if the cpu has to be busy while the gpu is working!<br>
<br>Regards<br><br> Nicola<br>