From: "Antonino A. Daplas" <adaplas@gmail.com>
To: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Andrew Morton <akpm@osdl.org>,
linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Jochen Hein <jochen@jochen.org>
Subject: Re: [PATCH 1/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts
Date: Wed, 31 Aug 2005 09:14:34 +0800 [thread overview]
Message-ID: <4315047A.4040907@gmail.com> (raw)
In-Reply-To: <43148610.70406@t-online.de>
Knut Petersen wrote:
> This trivial patch gives a performance boost to the framebuffer console
>
> Constructing the bitmaps that are given to the bitblit functions of the
> framebuffer
> drivers is time consuming. Here we avoide a call to the slow
> fb_pad_aligned_buffer().
> The patch replaces that call with a simple but much more efficient
> bytewise copy.
>
> The kernel spends a significant time at this place if you use 8x* fonts.
> Every
> pixel displayed on your screen is prepared here.
>
> Some benchmark results:
>
> Displaying a file of 2000 lines with 160 characters each takes 889 ms
> system
> time using cyblafb on my system (I´m using a 1280x1024 video mode,
> resulting in a 160x64 character console)
>
> Displaying the same file with the enclosed patch applied to 2.6.13 only
> takes
> 760 ms system time, saving 129 ms or 14.5%.
Where did this 14.5% come from? Is it bit_putcs alone or is more
real world, such as 'time cat text_file'? If I'm to guess, a large
percent of the improvement is caused by the inlining of the code.
I'm not against the patch, it will benefit drivers with very fast
imageblits. However, since most drivers have imageblits done in software,
a large proportion of the processing time will go to the imageblit itself,
so I don't think you'll get that high a number (I get only a 4%
improvement, and this is in a driver with accelerated blits, and it will
probably be lower, ie, in vesafb).
Anyway, with the addition of your patch, bit_putcs has now reached an
'ugliness threshhold' for a revamp.
Tony
prev parent reply other threads:[~2005-08-31 1:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-30 16:15 [PATCH 1/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts Knut Petersen
2005-08-30 16:18 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2005-08-30 17:58 ` Knut Petersen
2005-08-30 19:13 ` Roman Zippel
2005-08-30 22:26 ` Knut Petersen
2005-08-31 0:51 ` Roman Zippel
2005-08-31 6:42 ` Antonino A. Daplas
2005-08-31 15:49 ` Roman Zippel
2005-08-31 12:46 ` Knut Petersen
2005-08-31 17:15 ` Roman Zippel
2005-08-31 19:19 ` Knut Petersen
2005-08-31 19:34 ` Roman Zippel
2005-08-31 19:52 ` Knut Petersen
2005-08-30 19:59 ` Geert Uytterhoeven
2005-08-31 1:14 ` Antonino A. Daplas
2005-08-31 1:14 ` Antonino A. Daplas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4315047A.4040907@gmail.com \
--to=adaplas@gmail.com \
--cc=Knut_Petersen@t-online.de \
--cc=akpm@osdl.org \
--cc=jochen@jochen.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox