-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 04/01/2014 03:29 PM, Tomi Valkeinen wrote:
> On 01/04/14 14:41, Grazvydas Ignotas wrote:
>> Hi,
>>
>> Nice, thanks for figuring it out.
>
> Btw, please try to add me in "To:" for the post, as I may well miss the
> reply if it's not directed to me.


ok..

>
>> On Tue, Apr 1, 2014 at 9:58 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> I was able to get rid of the L3 errors when using TILER 2D buffer. Patch
>>> attached. It's illegal to use caching on TILER 2D buffers, so that was
>>> causing the issues.
>>
>> Hmm, that was write combining, not caching. Shame even that doesn't
>
> I was using "caching" in the broad sense. write-combining is a form of
> caching. So the only allowed option is to disable all caching.
>
> I have to say I'm not 100% sure about the above. It maybe that
> write-combining works with certain kinds of CPU accesses. But I still
> guess that disabling the caching is a safe generic fix here.
>
>> work, accessing strongly ordered memory will be very slow even if the
>> page fault problem is fixed.
>
> I don't know about "very slow", but yes, it will definitely affect the
> performance. Do you happen to have any numbers?


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)

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.

>
> Do you have any ideas what kind of access patters to the fb are common?
> Is it normal to draw pixels here and there? I hope not. If the normal
> pattern is to copy bigger pieces to the framebuffer, the performance hit
> may not be huge (just guessing).


It depends on the program.. Something like drawing small 8x8 sprites at random locations is not that uncommon. On pandora we're using huge pages and it helps with TLB misses at least (drawing vertical lines, for example, is several times faster on huge pages).

>
>
>> It sucks having to use a shadow buffer, even if DMA does it, it still
>> means additional ~1GB/s of memory bandwidth wasted (~500MB/s for
>> reading + ~500MB/s for writing to TILER), which adds to ~500MB/s
>> needed for DISPC to update the screen and whatever is needed for CPU
>> to draw the frame. I hope ED makes the right decision and at least
>> uses lower resolution screen.
>
> Yes, I agree. TILER + very high resolution screen sounds risky to me, if
> the target is to support "all" applications (as in, compared to, say,
> all apps working on top of android compositor which uses sgx or such).
>
>  Tomi
>
>
>
> _______________________________________________
> Kernel mailing list
> Kernel@pyra-handheld.com
> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTO2IgAAoJEDgePbfOWUniMsAH/18rEZmjXslZHxto3MxpUAt5
Qva2LITm+gPIUzeLV5HGxkI77HGhAPYVyq1U+Cpg468Hr07w/0lSyYzT8eeV/cN7
iZjDPYBENk1MXY5Fa6zYyo3SjZk7ERJ9WduoQ/22TWiUDyWtXJ8iRyY6S9U/qJbf
JFjjixFuFwV3QRPNPDkhij6qPiZ7M2fy7mnXSnrkvPZGRR8Ykm7FKXZAUhRM8H7o
fvPkEGLA19XgpO7/4x9Pkitea6h2ZD3hU/WPoqlOvBSV+z/yvNZKx3fVG50Awe6T
rBo+Fw1RA8okt/69DSaydUoOus6P6cNZ75Kq1jxB5BDQOv1Ld7yKJ/YwoE9WZgo=
=yrB2
-----END PGP SIGNATURE-----