-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| we'd be much better off). this was the crux behind the DMA experiment dodji | did. the problem was that the DMA was on-soc and memory to memory and would hold This test tells you more that the DMA one. There are two discrete things going on that make Glamo access slow: ~ - we pace ourselves at the CPU with waitstates to be REALLY slow if we touch Glamo. If we don't do that we get unstable communication and visual artefacts. ~ - the Glamo paces US according to its own private arbitration of the internal DRAM between us and, eg, the video controller inside Glamo that is also constantly needing access to same RAM to update the LCM It's clear both of these are significant because when I reduce the CPU waitstates things go faster, but the Glamo arbitration blocking is still there. | up the cpu in wait states anyway - so you don't win over using the cpu. it was | 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. | benefits. :( unfortunately your example (the sliding top-bar) isn't even the | best example of cpu waitstates caused by the glamo. i have manufactured much | worse artificial ones :) you might want to try scrolling in exposure as another | test... :) Exposure doesn't seem to start on the image I have from today. Says it is starting and then nothing. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh7XM4ACgkQOjLpvpq7dMrbrQCggkbHzaS5SkwQiDVVv1SfYEMR J78AnRrxim1vEIAioy3TSss35xzeaojj =lUPn -----END PGP SIGNATURE-----
