Re: Fw: framebuffer blitting performance loss 2.6.12 -> 2.6.13-rc3

Knut Petersen wrote:

Hi everybody!

quoted

quoted

I haven't seen any significant performance penalty, between 2.6.12-rc5-mm1
and 2.6.13-rc3-mm1.

Based on your results, I would pinpoint the culprit to be in
video/console/bitblit.c.  However, the changes there are minor, and should not
alter the peformance.

So.. what happened here?  Is the problem still present in 2.6.13-rc4?

Yes, the problem still is present in 2.6.13-rc4.
================================================

Thank you for your persistence.  I think I know the culprit.  Someone
insisted on using memcpy in fb_pad_aligned_buffer().  I have already
fixed this before, but apparently, the memcpy was brought back.  Try
the attached patch and let me know.

Tony

  fbdev: Replace memcpy with for-loop when preparing bitmap

   Do not use memcpy in fb_pad_aligned_buffer. It is suboptimal because only
   a few bytes are moved at a time. Replace with a for-loop.

   From: Antonino Daplas [off-list ref]
   Signed-off-by: Antonino Daplas [off-list ref]
---

fbmem.c |    6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c

@@ -80,10 +80,12 @@ EXPORT_SYMBOL(fb_get_color_depth);
 */

void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 s_pitch, u32 height)
{
-	int i;
+	int i, j;

	for (i = height; i--; ) {
-		memcpy(dst, src, s_pitch);
+		/* s_pitch is a few bytes at the most, memcpy is suboptimal */
+		for (j = 0; j < s_pitch; j++)
+			dst[j] = src[j];
		src += s_pitch;
		dst += d_pitch;
	}


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf