[lkml]   [2015]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: simple framebuffer slower by factor of 20, on socfpga (arm) platform
On 09/04/15 14:21, Tomi Valkeinen wrote:
> On 09/04/15 14:06, Pavel Machek wrote:
>> On Tue 2015-04-07 14:19:33, Geert Uytterhoeven wrote:
>>> Hi Pavel,
>>> On Tue, Apr 7, 2015 at 2:12 PM, Pavel Machek <> wrote:
>>>> I have an socfpga board, which uses has simple framebuffer implemented
>>>> in the FPGA. On 3.15, framebuffer is fast:
>>>> root@wagabuibui:~# time cat /dev/fb0 > /dev/null
>>>> real 0m 0.00s
>>>> user 0m 0.00s
>>>> sys 0m 0.00s
>>>> on 3.18, this takes 220msec. Similar slowdown exists for
>>>> writes. Simple framebuffer did not change at all between 3.15 and
>>>> 3.18; resource flags of the framebuffer are still same (0x200).
>>>> If I enable caching on 3.18, it speeds up a bit, to 70msec or
>>>> so... Which means problem is not only in caching.
>>>> Any ideas?
>>> My first guess was commit 67dc0d4758e5 ("vt_buffer: drop console buffer
>>> copying optimisations"), but this was introduced only in v4.0-rc1.
>>> Just in case you encounter another performance regression after upgrading
>>> to a more modern kernel ;-)
>> :-). I did a git bisect, and it pointed to this. And reverting it
>> indeed fixes the problem in 3.18. Problem is still there in 4.0.

The difference is probably caused by memcpy() vs memcpy_fromio(). The
comment above memcpy_fromio() says "This needs to be optimized". I think
generally speaking memcpy_fromio() is correct for a framebuffer.

That said, if the fb is in RAM, and is only written by the CPU, I think
a normal memcpy() for fb_memcpy_fromfb() should be fine...


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2015-04-09 14:01    [W:0.109 / U:0.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site