On 02/04/14 04:17, Grazvydas Ignotas wrote:
It seems my mail client reacted strangely to Tomi's signature, maybe this will look better.
Odd... Well, you're sending plaintext+html emails, not only plaintext mails, even though the older emails from you were plain plaintext mails.
On 04/02/2014 04:04 AM, Grazvydas Ignotas wrote:
On 04/01/2014 03:29 PM, Tomi Valkeinen wrote:
I've measured it now by using omap_bo_new(), which creates 1D (nontiled) buffer object and allows to specify OMAP_BO_* cacheability flags. I've hacked it to always use contiguous buffers too and verified that no page faults are happening. Tests are done on 1080*1920 32bpp buffer, first number pair is from constantly redrawing color patterns (memset() basically), second is memcpy() from normal buffer.
OMAP_BO_CACHED: ~550fps (~4GB/s), 192fps (1518 MB/s) (there is corruption on screen and performance is too high as I'm not flushing cache, so some writes are probably hitting cache and not reaching RAM) OMAP_BO_WC: 120fps (940MB/s), 126fps (996MB/s) OMAP_BO_UNCACHED: 8fps (~64MB/s), 16fps (126MB/s) (I'm unsure why memcpy is faster, I think it's because it's using NEON stores)
Yes, I think memcpy may use NEON. I also understood (from a TI internal mail thread) that using NEON to copy to/from TILER may be illegal, as with NEON something related to memory accesses is undefined and may not be compatible with TILER. But, I really didn't quite understand it all, so I may not be right.
As you can see as uncached/strongly ordered it's pretty much unusable. I remember the same from my tests on OMAP3. ARM manual states that ARM has to wait for acknowledge of every write of strongly ordered memory, no wonder it's so slow.
Yes, TILER does really sound unusable with CPU. I'll try to ask internally for verification.
Tomi