nWAITing for Glamo
Werner Almesberger
werner at openmoko.org
Wed Jul 16 00:52:34 CEST 2008
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.
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 ;-)
- Werner
More information about the openmoko-kernel
mailing list