-----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 <[EMAIL PROTECTED]> 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. If both were memcpy()-type action then it's still a mystery. - -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-----
