-----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-----