nWAITing for Glamo

[Carsten Haitzler (The Rasterman)]

On Tue, 15 Jul 2008 19:52:34 -0300 Werner Almesberger <werner at openmoko.org>
babbled:

> Carsten Haitzler wrote:
> > hmmmm. interesting idea. this is only possible to do sanely with dma
> 
> You could probably control this also by carefully scheduling instructions.
> E.g., instead of
> 
> 	compute A and B
> 	write A to glamo
> 	write B to glamo
> 	do C
> 
> you could
> 
> 	compute A
> 	write A to glamo
> 	compute B
> 	write B to glamo
> 	do C
> 
> or
> 
> 	compute A and B
> 	write A to glamo
> 	do C
> 	write B to glamo
> 
> This would be hell to implement for all accesses, but if you have
> certain structures of accesses, they could be done in small hand-tuned
> functions. For bulk transfers, you need DMA.

oh man..not just hell - but nigh imposible. in general you compute a whole
buffer of pixels - often a whole window or screen worth - or at least an update
region of several hundred pixels - at a minimum, if not several thousand,
ten-thousand, THEN you upload it when is done. ouch. it's likley not going to
fly though.

> It's an interesting idea. Whether it works depends largely when the
> Glamo samples the data: at the beginning or at the end of the cycle.
> 
> Whether it's useful also depends on whether there is really a lot of
> other things the system can do. Since this is likely to be slower than
> a burst copy, you only win if the bottleneck of the application isn't
> the amount of data that gets moved to the Glamo.
> 
> In a GUI, sheer transfer rate is probably the bottleneck. In video
> playback, there may be an opportunity to interleave decompression
> with frame buffer access. Should be fun to implement, though ;-)

pretty much anything that does animation and is uploading data a lot - updated
images, frames etc. is going to suffer badly from glamo. i've done tests with
an old software-only 3d enigne i wrote years ago for 16bpp. if we have a 2442
with a dumb framebuffer i'd get 13fps. the glamo drops it to 7fps from 13 due
to the wait on the copy-to-glamo, so that gives you an idea of the impact on a
software 3d engine which does have enough computer to do between pixel uploads.
the less compute needed for the pixel creation, the higher the impact. :(

-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>