nWAITing for Glamo

Carsten Haitzler (The Rasterman) raster at openmoko.org
Tue Jul 15 20:38:07 CEST 2008


On Tue, 15 Jul 2008 18:46:03 +0100 Andy Green <andy at openmoko.com> babbled:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> zero
> | |
> | | 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.

oh - i know! memset will negate the need for a src read. the problem is... it's
a "useless case". :( the only useful use case is a memcpy() to the glamo. :)
both cases were "copies" the memcpy() to the glamo with cpu and the dma copy to
glamo... apples vs. apples. :)

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

they were. stil a mystery - but we wasted maybe 3 weeks on dma? it was a slim
hope - if it had worked (given the glamo has limited write cycles) we at LEAST
would have freed up the cpu to do something more useful with its life while
dma'ing to the glamo... but alas. was not to be.

all i want for christmas is a new SOC... that doesn't suck! that has a built-in
gpu that is open and fast... and accelerates all the operations we could
possibly need or want... nicely. aaah.. i can dream!

know anything about that qualcomm snapdragon SOC? got 3.5g, 1ghz arm and
apparently some ATI base graphics core. pretty scant on details, but if its
really an ATI core... maybe... we can.... then again... it's qualcomm...

back to dreaming... :)

> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkh84lUACgkQOjLpvpq7dMrG1wCgiFr4yB3IhyK6cFY08R6iKGa4
> LtIAn2l/N38WEdWTfWqGJ3GM5nvGb00Q
> =n0ab
> -----END PGP SIGNATURE-----


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




More information about the openmoko-kernel mailing list