nWAITing for Glamo

Andy Green andy at openmoko.com
Tue Jul 15 19:46:03 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Tue, 15 Jul 2008 10:39:01 +0100 Andy Green <andy at openmoko.com> babbled:
| Somebody in the thread at some point said:
| | | actually worse as you also have dma setup overhead etc. at best it
| | seemed to
| | | pull about half the throughput of copying with the cpu, and gained
| |
| | Something funny there then, it shouldn't've been any worse.  If most of
| | the trouble is coming from Glamo just covering its ears it might not
| | have made much odds but should only have been the same or faster.
| Carsten are you sure you tested the same thing each time?  It sounds
| like the first time you spammed Glamo memory with a constant, so the
| memory bus was dedicated to Glamo access actions and the CPU ran from
| cache (and had its constant from CPU register).
|> both times we were trying to
|> 1. test throughput - write to the glamo as fast as possible. in this
case we
|> were in waitstates using the cpu waiting for the glamo to accept all our
|> writes. this is one of the big performance issues - when doing
redraws of a big
|> region of the screen an upload may be 200kb up to 600kb - for 1
frame. rinse
|> and repeat. we just get stuck waiting for glamo.

What I'm getting at is that if you did a memset() to Glamo it will go a
lot faster than if you did a memcpy().  If the first test was of the
memset() variety it would explain why DMA seems half the speed.

If both were memcpy()-type action then it's still a mystery.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list