nWAITing for Glamo

[Crane, Matthew]

Is it possible to do transfers from a timer interrupt to get a
pseudo-dma operation?  E.g the std arm7 method of dma.  Or likely that
would be too slow. 


-----Original Message-----
From: openmoko-kernel-bounces at lists.openmoko.org
[mailto:openmoko-kernel-bounces at lists.openmoko.org] On Behalf Of Carsten
Haitzler (The Rasterman)
Sent: Tuesday, July 15, 2008 7:13 PM
To: Werner Almesberger
Cc: openmoko-kernel at lists.openmoko.org
Subject: Re: nWAITing for Glamo


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>