[PATCH v3 0/5] fbdev: Improve performance of fbdev console

[PATCH v3 0/5] fbdev: Improve performance of fbdev console

[Thomas Zimmermann]

Optimize performance of the fbdev console for the common case of
software-based clearing and image blitting.

The commit descripton of each patch contains resuls os a simple
microbenchmark. I also tested the full patchset's effect on the
console output by printing directory listings (i7-4790, FullHD,
simpledrm, kernel with debugging).

  > time find /usr/share/doc -type f

In the unoptimized case:

  real    0m6.173s
  user    0m0.044s
  sys     0m6.107s

With optimizations applied:

  real    0m4.754s
  user    0m0.044s
  sys     0m4.698s

In the optimized case, printing the directory listing is ~25% faster
than before.

In v2 of the patchset, after implementing Sam's suggestion to update
cfb_imageblit() as well, it turns out that the compiled code in
sys_imageblit() is still significantly slower than the CFB version. A
fix is probably a larger task and would include architecture-specific
changes. A new TODO item suggests to investigate the performance of the
various helpers and format-conversion functions in DRM and fbdev.

v3:
	* fix description of cfb_imageblit() patch (Pekka)
v2:
	* improve readability for sys_imageblit() (Gerd, Sam)
	* new TODO item for further optimization

Thomas Zimmermann (5):
  fbdev: Improve performance of sys_fillrect()
  fbdev: Improve performance of sys_imageblit()
  fbdev: Remove trailing whitespaces from cfbimgblt.c
  fbdev: Improve performance of cfb_imageblit()
  drm: Add TODO item for optimizing format helpers

 Documentation/gpu/todo.rst             |  22 +++++
 drivers/video/fbdev/core/cfbimgblt.c   | 107 ++++++++++++++++---------
 drivers/video/fbdev/core/sysfillrect.c |  16 +---
 drivers/video/fbdev/core/sysimgblt.c   |  49 ++++++++---
 4 files changed, 133 insertions(+), 61 deletions(-)

-- 
2.35.1

[PATCH v3 0/5] fbdev: Improve performance of fbdev console

[Thomas Zimmermann]

Optimize performance of the fbdev console for the common case of
software-based clearing and image blitting.

The commit descripton of each patch contains resuls os a simple
microbenchmark. I also tested the full patchset's effect on the
console output by printing directory listings (i7-4790, FullHD,
simpledrm, kernel with debugging).

  > time find /usr/share/doc -type f

In the unoptimized case:

  real    0m6.173s
  user    0m0.044s
  sys     0m6.107s

With optimizations applied:

  real    0m4.754s
  user    0m0.044s
  sys     0m4.698s

In the optimized case, printing the directory listing is ~25% faster
than before.

In v2 of the patchset, after implementing Sam's suggestion to update
cfb_imageblit() as well, it turns out that the compiled code in
sys_imageblit() is still significantly slower than the CFB version. A
fix is probably a larger task and would include architecture-specific
changes. A new TODO item suggests to investigate the performance of the
various helpers and format-conversion functions in DRM and fbdev.

v3:
	* fix description of cfb_imageblit() patch (Pekka)
v2:
	* improve readability for sys_imageblit() (Gerd, Sam)
	* new TODO item for further optimization

Thomas Zimmermann (5):
  fbdev: Improve performance of sys_fillrect()
  fbdev: Improve performance of sys_imageblit()
  fbdev: Remove trailing whitespaces from cfbimgblt.c
  fbdev: Improve performance of cfb_imageblit()
  drm: Add TODO item for optimizing format helpers

 Documentation/gpu/todo.rst             |  22 +++++
 drivers/video/fbdev/core/cfbimgblt.c   | 107 ++++++++++++++++---------
 drivers/video/fbdev/core/sysfillrect.c |  16 +---
 drivers/video/fbdev/core/sysimgblt.c   |  49 ++++++++---
 4 files changed, 133 insertions(+), 61 deletions(-)

-- 
2.35.1

[PATCH v3 1/5] fbdev: Improve performance of sys_fillrect()

[Thomas Zimmermann]

Improve the performance of sys_fillrect() by using word-aligned
32/64-bit mov instructions. While the code tried to implement this,
the compiler failed to create fast instructions. The resulting
binary instructions were even slower than cfb_fillrect(), which
uses the same algorithm, but operates on I/O memory.

A microbenchmark measures the average number of CPU cycles
for sys_fillrect() after a stabilizing period of a few minutes
(i7-4790, FullHD, simpledrm, kernel with debugging). The value
for CFB is given as a reference.

  sys_fillrect(), new:  26586 cycles
  sys_fillrect(), old: 166603 cycles
  cfb_fillrect():       41012 cycles

In the optimized case, sys_fillrect() is now ~6x faster than before
and ~1.5x faster than the CFB implementation.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
---
 drivers/video/fbdev/core/sysfillrect.c | 16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/video/fbdev/core/sysfillrect.c b/drivers/video/fbdev/core/sysfillrect.c
index 33ee3d34f9d2..bcdcaeae6538 100644
--- a/drivers/video/fbdev/core/sysfillrect.c
+++ b/drivers/video/fbdev/core/sysfillrect.c
@@ -50,19 +50,9 @@ bitfill_aligned(struct fb_info *p, unsigned long *dst, int dst_idx,
 
 		/* Main chunk */
 		n /= bits;
-		while (n >= 8) {
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			n -= 8;
-		}
-		while (n--)
-			*dst++ = pat;
+		memset_l(dst, pat, n);
+		dst += n;
+
 		/* Trailing bits */
 		if (last)
 			*dst = comp(pat, *dst, last);
-- 
2.35.1

[PATCH v3 1/5] fbdev: Improve performance of sys_fillrect()

[Thomas Zimmermann]

Improve the performance of sys_fillrect() by using word-aligned
32/64-bit mov instructions. While the code tried to implement this,
the compiler failed to create fast instructions. The resulting
binary instructions were even slower than cfb_fillrect(), which
uses the same algorithm, but operates on I/O memory.

A microbenchmark measures the average number of CPU cycles
for sys_fillrect() after a stabilizing period of a few minutes
(i7-4790, FullHD, simpledrm, kernel with debugging). The value
for CFB is given as a reference.

  sys_fillrect(), new:  26586 cycles
  sys_fillrect(), old: 166603 cycles
  cfb_fillrect():       41012 cycles

In the optimized case, sys_fillrect() is now ~6x faster than before
and ~1.5x faster than the CFB implementation.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
---
 drivers/video/fbdev/core/sysfillrect.c | 16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/video/fbdev/core/sysfillrect.c b/drivers/video/fbdev/core/sysfillrect.c
index 33ee3d34f9d2..bcdcaeae6538 100644
--- a/drivers/video/fbdev/core/sysfillrect.c
+++ b/drivers/video/fbdev/core/sysfillrect.c
@@ -50,19 +50,9 @@ bitfill_aligned(struct fb_info *p, unsigned long *dst, int dst_idx,
 
 		/* Main chunk */
 		n /= bits;
-		while (n >= 8) {
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			*dst++ = pat;
-			n -= 8;
-		}
-		while (n--)
-			*dst++ = pat;
+		memset_l(dst, pat, n);
+		dst += n;
+
 		/* Trailing bits */
 		if (last)
 			*dst = comp(pat, *dst, last);
-- 
2.35.1

[PATCH v3 2/5] fbdev: Improve performance of sys_imageblit()

[Thomas Zimmermann]

Improve the performance of sys_imageblit() by manually unrolling
the inner blitting loop and moving some invariants out. The compiler
failed to do this automatically. The resulting binary code was even
slower than the cfb_imageblit() helper, which uses the same algorithm,
but operates on I/O memory.

A microbenchmark measures the average number of CPU cycles
for sys_imageblit() after a stabilizing period of a few minutes
(i7-4790, FullHD, simpledrm, kernel with debugging). The value
for CFB is given as a reference.

  sys_imageblit(), new: 25934 cycles
  sys_imageblit(), old: 35944 cycles
  cfb_imageblit():      30566 cycles

In the optimized case, sys_imageblit() is now ~30% faster than before
and ~20% faster than cfb_imageblit().

v2:
	* move switch out of inner loop (Gerd)
	* remove test for alignment of dst1 (Sam)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
---
 drivers/video/fbdev/core/sysimgblt.c | 49 +++++++++++++++++++++-------
 1 file changed, 38 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/core/sysimgblt.c b/drivers/video/fbdev/core/sysimgblt.c
index a4d05b1b17d7..722c327a381b 100644
--- a/drivers/video/fbdev/core/sysimgblt.c
+++ b/drivers/video/fbdev/core/sysimgblt.c
@@ -188,23 +188,29 @@ static void fast_imageblit(const struct fb_image *image, struct fb_info *p,
 {
 	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
 	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
-	u32 bit_mask, end_mask, eorx, shift;
+	u32 bit_mask, eorx;
 	const char *s = image->data, *src;
 	u32 *dst;
-	const u32 *tab = NULL;
+	const u32 *tab;
+	size_t tablen;
+	u32 colortab[16];
 	int i, j, k;
 
 	switch (bpp) {
 	case 8:
 		tab = fb_be_math(p) ? cfb_tab8_be : cfb_tab8_le;
+		tablen = 16;
 		break;
 	case 16:
 		tab = fb_be_math(p) ? cfb_tab16_be : cfb_tab16_le;
+		tablen = 4;
 		break;
 	case 32:
-	default:
 		tab = cfb_tab32;
+		tablen = 2;
 		break;
+	default:
+		return;
 	}
 
 	for (i = ppw-1; i--; ) {
@@ -218,19 +224,40 @@ static void fast_imageblit(const struct fb_image *image, struct fb_info *p,
 	eorx = fgx ^ bgx;
 	k = image->width/ppw;
 
+	for (i = 0; i < tablen; ++i)
+		colortab[i] = (tab[i] & eorx) ^ bgx;
+
 	for (i = image->height; i--; ) {
 		dst = dst1;
-		shift = 8;
 		src = s;
 
-		for (j = k; j--; ) {
-			shift -= ppw;
-			end_mask = tab[(*src >> shift) & bit_mask];
-			*dst++ = (end_mask & eorx) ^ bgx;
-			if (!shift) {
-				shift = 8;
-				src++;
+		switch (ppw) {
+		case 4: /* 8 bpp */
+			for (j = k; j; j -= 2, ++src) {
+				*dst++ = colortab[(*src >> 4) & bit_mask];
+				*dst++ = colortab[(*src >> 0) & bit_mask];
+			}
+			break;
+		case 2: /* 16 bpp */
+			for (j = k; j; j -= 4, ++src) {
+				*dst++ = colortab[(*src >> 6) & bit_mask];
+				*dst++ = colortab[(*src >> 4) & bit_mask];
+				*dst++ = colortab[(*src >> 2) & bit_mask];
+				*dst++ = colortab[(*src >> 0) & bit_mask];
+			}
+			break;
+		case 1: /* 32 bpp */
+			for (j = k; j; j -= 8, ++src) {
+				*dst++ = colortab[(*src >> 7) & bit_mask];
+				*dst++ = colortab[(*src >> 6) & bit_mask];
+				*dst++ = colortab[(*src >> 5) & bit_mask];
+				*dst++ = colortab[(*src >> 4) & bit_mask];
+				*dst++ = colortab[(*src >> 3) & bit_mask];
+				*dst++ = colortab[(*src >> 2) & bit_mask];
+				*dst++ = colortab[(*src >> 1) & bit_mask];
+				*dst++ = colortab[(*src >> 0) & bit_mask];
 			}
+			break;
 		}
 		dst1 += p->fix.line_length;
 		s += spitch;
-- 
2.35.1

[PATCH v3 2/5] fbdev: Improve performance of sys_imageblit()

[Thomas Zimmermann]

Improve the performance of sys_imageblit() by manually unrolling
the inner blitting loop and moving some invariants out. The compiler
failed to do this automatically. The resulting binary code was even
slower than the cfb_imageblit() helper, which uses the same algorithm,
but operates on I/O memory.

A microbenchmark measures the average number of CPU cycles
for sys_imageblit() after a stabilizing period of a few minutes
(i7-4790, FullHD, simpledrm, kernel with debugging). The value
for CFB is given as a reference.

  sys_imageblit(), new: 25934 cycles
  sys_imageblit(), old: 35944 cycles
  cfb_imageblit():      30566 cycles

In the optimized case, sys_imageblit() is now ~30% faster than before
and ~20% faster than cfb_imageblit().

v2:
	* move switch out of inner loop (Gerd)
	* remove test for alignment of dst1 (Sam)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
---
 drivers/video/fbdev/core/sysimgblt.c | 49 +++++++++++++++++++++-------
 1 file changed, 38 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/core/sysimgblt.c b/drivers/video/fbdev/core/sysimgblt.c
index a4d05b1b17d7..722c327a381b 100644
--- a/drivers/video/fbdev/core/sysimgblt.c
+++ b/drivers/video/fbdev/core/sysimgblt.c
@@ -188,23 +188,29 @@ static void fast_imageblit(const struct fb_image *image, struct fb_info *p,
 {
 	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
 	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
-	u32 bit_mask, end_mask, eorx, shift;
+	u32 bit_mask, eorx;
 	const char *s = image->data, *src;
 	u32 *dst;
-	const u32 *tab = NULL;
+	const u32 *tab;
+	size_t tablen;
+	u32 colortab[16];
 	int i, j, k;
 
 	switch (bpp) {
 	case 8:
 		tab = fb_be_math(p) ? cfb_tab8_be : cfb_tab8_le;
+		tablen = 16;
 		break;
 	case 16:
 		tab = fb_be_math(p) ? cfb_tab16_be : cfb_tab16_le;
+		tablen = 4;
 		break;
 	case 32:
-	default:
 		tab = cfb_tab32;
+		tablen = 2;
 		break;
+	default:
+		return;
 	}
 
 	for (i = ppw-1; i--; ) {
@@ -218,19 +224,40 @@ static void fast_imageblit(const struct fb_image *image, struct fb_info *p,
 	eorx = fgx ^ bgx;
 	k = image->width/ppw;
 
+	for (i = 0; i < tablen; ++i)
+		colortab[i] = (tab[i] & eorx) ^ bgx;
+
 	for (i = image->height; i--; ) {
 		dst = dst1;
-		shift = 8;
 		src = s;
 
-		for (j = k; j--; ) {
-			shift -= ppw;
-			end_mask = tab[(*src >> shift) & bit_mask];
-			*dst++ = (end_mask & eorx) ^ bgx;
-			if (!shift) {
-				shift = 8;
-				src++;
+		switch (ppw) {
+		case 4: /* 8 bpp */
+			for (j = k; j; j -= 2, ++src) {
+				*dst++ = colortab[(*src >> 4) & bit_mask];
+				*dst++ = colortab[(*src >> 0) & bit_mask];
+			}
+			break;
+		case 2: /* 16 bpp */
+			for (j = k; j; j -= 4, ++src) {
+				*dst++ = colortab[(*src >> 6) & bit_mask];
+				*dst++ = colortab[(*src >> 4) & bit_mask];
+				*dst++ = colortab[(*src >> 2) & bit_mask];
+				*dst++ = colortab[(*src >> 0) & bit_mask];
+			}
+			break;
+		case 1: /* 32 bpp */
+			for (j = k; j; j -= 8, ++src) {
+				*dst++ = colortab[(*src >> 7) & bit_mask];
+				*dst++ = colortab[(*src >> 6) & bit_mask];
+				*dst++ = colortab[(*src >> 5) & bit_mask];
+				*dst++ = colortab[(*src >> 4) & bit_mask];
+				*dst++ = colortab[(*src >> 3) & bit_mask];
+				*dst++ = colortab[(*src >> 2) & bit_mask];
+				*dst++ = colortab[(*src >> 1) & bit_mask];
+				*dst++ = colortab[(*src >> 0) & bit_mask];
 			}
+			break;
 		}
 		dst1 += p->fix.line_length;
 		s += spitch;
-- 
2.35.1

[PATCH v3 3/5] fbdev: Remove trailing whitespaces from cfbimgblt.c

[Thomas Zimmermann]

Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/video/fbdev/core/cfbimgblt.c | 60 ++++++++++++++--------------
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/video/fbdev/core/cfbimgblt.c b/drivers/video/fbdev/core/cfbimgblt.c
index a2bb276a8b24..01b01a279681 100644
--- a/drivers/video/fbdev/core/cfbimgblt.c
+++ b/drivers/video/fbdev/core/cfbimgblt.c
@@ -16,15 +16,15 @@
  *  must be laid out exactly in the same format as the framebuffer. Yes I know
  *  their are cards with hardware that coverts images of various depths to the
  *  framebuffer depth. But not every card has this. All images must be rounded
- *  up to the nearest byte. For example a bitmap 12 bits wide must be two 
- *  bytes width. 
+ *  up to the nearest byte. For example a bitmap 12 bits wide must be two
+ *  bytes width.
  *
- *  Tony: 
- *  Incorporate mask tables similar to fbcon-cfb*.c in 2.4 API.  This speeds 
+ *  Tony:
+ *  Incorporate mask tables similar to fbcon-cfb*.c in 2.4 API.  This speeds
  *  up the code significantly.
- *  
+ *
  *  Code for depths not multiples of BITS_PER_LONG is still kludgy, which is
- *  still processed a bit at a time.   
+ *  still processed a bit at a time.
  *
  *  Also need to add code to deal with cards endians that are different than
  *  the native cpu endians. I also need to deal with MSB position in the word.
@@ -72,8 +72,8 @@ static const u32 cfb_tab32[] = {
 #define FB_WRITEL fb_writel
 #define FB_READL  fb_readl
 
-static inline void color_imageblit(const struct fb_image *image, 
-				   struct fb_info *p, u8 __iomem *dst1, 
+static inline void color_imageblit(const struct fb_image *image,
+				   struct fb_info *p, u8 __iomem *dst1,
 				   u32 start_index,
 				   u32 pitch_index)
 {
@@ -92,7 +92,7 @@ static inline void color_imageblit(const struct fb_image *image,
 		dst = (u32 __iomem *) dst1;
 		shift = 0;
 		val = 0;
-		
+
 		if (start_index) {
 			u32 start_mask = ~fb_shifted_pixels_mask_u32(p,
 						start_index, bswapmask);
@@ -109,8 +109,8 @@ static inline void color_imageblit(const struct fb_image *image,
 			val |= FB_SHIFT_HIGH(p, color, shift ^ bswapmask);
 			if (shift >= null_bits) {
 				FB_WRITEL(val, dst++);
-	
-				val = (shift == null_bits) ? 0 : 
+
+				val = (shift == null_bits) ? 0 :
 					FB_SHIFT_LOW(p, color, 32 - shift);
 			}
 			shift += bpp;
@@ -134,9 +134,9 @@ static inline void color_imageblit(const struct fb_image *image,
 	}
 }
 
-static inline void slow_imageblit(const struct fb_image *image, struct fb_info *p, 
+static inline void slow_imageblit(const struct fb_image *image, struct fb_info *p,
 				  u8 __iomem *dst1, u32 fgcolor,
-				  u32 bgcolor, 
+				  u32 bgcolor,
 				  u32 start_index,
 				  u32 pitch_index)
 {
@@ -172,7 +172,7 @@ static inline void slow_imageblit(const struct fb_image *image, struct fb_info *
 			l--;
 			color = (*s & (1 << l)) ? fgcolor : bgcolor;
 			val |= FB_SHIFT_HIGH(p, color, shift ^ bswapmask);
-			
+
 			/* Did the bitshift spill bits to the next long? */
 			if (shift >= null_bits) {
 				FB_WRITEL(val, dst++);
@@ -191,16 +191,16 @@ static inline void slow_imageblit(const struct fb_image *image, struct fb_info *
 
 			FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
 		}
-		
+
 		dst1 += pitch;
-		src += spitch;	
+		src += spitch;
 		if (pitch_index) {
 			dst2 += pitch;
 			dst1 = (u8 __iomem *)((long __force)dst2 & ~(sizeof(u32) - 1));
 			start_index += pitch_index;
 			start_index &= 32 - 1;
 		}
-		
+
 	}
 }
 
@@ -212,9 +212,9 @@ static inline void slow_imageblit(const struct fb_image *image, struct fb_info *
  *           fix->line_legth is divisible by 4;
  *           beginning and end of a scanline is dword aligned
  */
-static inline void fast_imageblit(const struct fb_image *image, struct fb_info *p, 
-				  u8 __iomem *dst1, u32 fgcolor, 
-				  u32 bgcolor) 
+static inline void fast_imageblit(const struct fb_image *image, struct fb_info *p,
+				  u8 __iomem *dst1, u32 fgcolor,
+				  u32 bgcolor)
 {
 	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
 	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
@@ -243,25 +243,25 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
 		fgx |= fgcolor;
 		bgx |= bgcolor;
 	}
-	
+
 	bit_mask = (1 << ppw) - 1;
 	eorx = fgx ^ bgx;
 	k = image->width/ppw;
 
 	for (i = image->height; i--; ) {
 		dst = (u32 __iomem *) dst1, shift = 8; src = s;
-		
+
 		for (j = k; j--; ) {
 			shift -= ppw;
 			end_mask = tab[(*src >> shift) & bit_mask];
 			FB_WRITEL((end_mask & eorx)^bgx, dst++);
-			if (!shift) { shift = 8; src++; }		
+			if (!shift) { shift = 8; src++; }
 		}
 		dst1 += p->fix.line_length;
 		s += spitch;
 	}
-}	
-	
+}
+
 void cfb_imageblit(struct fb_info *p, const struct fb_image *image)
 {
 	u32 fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
@@ -292,13 +292,13 @@ void cfb_imageblit(struct fb_info *p, const struct fb_image *image)
 		} else {
 			fgcolor = image->fg_color;
 			bgcolor = image->bg_color;
-		}	
-		
-		if (32 % bpp == 0 && !start_index && !pitch_index && 
+		}
+
+		if (32 % bpp == 0 && !start_index && !pitch_index &&
 		    ((width & (32/bpp-1)) == 0) &&
-		    bpp >= 8 && bpp <= 32) 			
+		    bpp >= 8 && bpp <= 32)
 			fast_imageblit(image, p, dst1, fgcolor, bgcolor);
-		else 
+		else
 			slow_imageblit(image, p, dst1, fgcolor, bgcolor,
 					start_index, pitch_index);
 	} else
-- 
2.35.1

[PATCH v3 3/5] fbdev: Remove trailing whitespaces from cfbimgblt.c

[Thomas Zimmermann]

Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/video/fbdev/core/cfbimgblt.c | 60 ++++++++++++++--------------
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/video/fbdev/core/cfbimgblt.c b/drivers/video/fbdev/core/cfbimgblt.c
index a2bb276a8b24..01b01a279681 100644
--- a/drivers/video/fbdev/core/cfbimgblt.c
+++ b/drivers/video/fbdev/core/cfbimgblt.c
@@ -16,15 +16,15 @@
  *  must be laid out exactly in the same format as the framebuffer. Yes I know
  *  their are cards with hardware that coverts images of various depths to the
  *  framebuffer depth. But not every card has this. All images must be rounded
- *  up to the nearest byte. For example a bitmap 12 bits wide must be two 
- *  bytes width. 
+ *  up to the nearest byte. For example a bitmap 12 bits wide must be two
+ *  bytes width.
  *
- *  Tony: 
- *  Incorporate mask tables similar to fbcon-cfb*.c in 2.4 API.  This speeds 
+ *  Tony:
+ *  Incorporate mask tables similar to fbcon-cfb*.c in 2.4 API.  This speeds
  *  up the code significantly.
- *  
+ *
  *  Code for depths not multiples of BITS_PER_LONG is still kludgy, which is
- *  still processed a bit at a time.   
+ *  still processed a bit at a time.
  *
  *  Also need to add code to deal with cards endians that are different than
  *  the native cpu endians. I also need to deal with MSB position in the word.
@@ -72,8 +72,8 @@ static const u32 cfb_tab32[] = {
 #define FB_WRITEL fb_writel
 #define FB_READL  fb_readl
 
-static inline void color_imageblit(const struct fb_image *image, 
-				   struct fb_info *p, u8 __iomem *dst1, 
+static inline void color_imageblit(const struct fb_image *image,
+				   struct fb_info *p, u8 __iomem *dst1,
 				   u32 start_index,
 				   u32 pitch_index)
 {
@@ -92,7 +92,7 @@ static inline void color_imageblit(const struct fb_image *image,
 		dst = (u32 __iomem *) dst1;
 		shift = 0;
 		val = 0;
-		
+
 		if (start_index) {
 			u32 start_mask = ~fb_shifted_pixels_mask_u32(p,
 						start_index, bswapmask);
@@ -109,8 +109,8 @@ static inline void color_imageblit(const struct fb_image *image,
 			val |= FB_SHIFT_HIGH(p, color, shift ^ bswapmask);
 			if (shift >= null_bits) {
 				FB_WRITEL(val, dst++);
-	
-				val = (shift == null_bits) ? 0 : 
+
+				val = (shift == null_bits) ? 0 :
 					FB_SHIFT_LOW(p, color, 32 - shift);
 			}
 			shift += bpp;
@@ -134,9 +134,9 @@ static inline void color_imageblit(const struct fb_image *image,
 	}
 }
 
-static inline void slow_imageblit(const struct fb_image *image, struct fb_info *p, 
+static inline void slow_imageblit(const struct fb_image *image, struct fb_info *p,
 				  u8 __iomem *dst1, u32 fgcolor,
-				  u32 bgcolor, 
+				  u32 bgcolor,
 				  u32 start_index,
 				  u32 pitch_index)
 {
@@ -172,7 +172,7 @@ static inline void slow_imageblit(const struct fb_image *image, struct fb_info *
 			l--;
 			color = (*s & (1 << l)) ? fgcolor : bgcolor;
 			val |= FB_SHIFT_HIGH(p, color, shift ^ bswapmask);
-			
+
 			/* Did the bitshift spill bits to the next long? */
 			if (shift >= null_bits) {
 				FB_WRITEL(val, dst++);
@@ -191,16 +191,16 @@ static inline void slow_imageblit(const struct fb_image *image, struct fb_info *
 
 			FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
 		}
-		
+
 		dst1 += pitch;
-		src += spitch;	
+		src += spitch;
 		if (pitch_index) {
 			dst2 += pitch;
 			dst1 = (u8 __iomem *)((long __force)dst2 & ~(sizeof(u32) - 1));
 			start_index += pitch_index;
 			start_index &= 32 - 1;
 		}
-		
+
 	}
 }
 
@@ -212,9 +212,9 @@ static inline void slow_imageblit(const struct fb_image *image, struct fb_info *
  *           fix->line_legth is divisible by 4;
  *           beginning and end of a scanline is dword aligned
  */
-static inline void fast_imageblit(const struct fb_image *image, struct fb_info *p, 
-				  u8 __iomem *dst1, u32 fgcolor, 
-				  u32 bgcolor) 
+static inline void fast_imageblit(const struct fb_image *image, struct fb_info *p,
+				  u8 __iomem *dst1, u32 fgcolor,
+				  u32 bgcolor)
 {
 	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
 	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
@@ -243,25 +243,25 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
 		fgx |= fgcolor;
 		bgx |= bgcolor;
 	}
-	
+
 	bit_mask = (1 << ppw) - 1;
 	eorx = fgx ^ bgx;
 	k = image->width/ppw;
 
 	for (i = image->height; i--; ) {
 		dst = (u32 __iomem *) dst1, shift = 8; src = s;
-		
+
 		for (j = k; j--; ) {
 			shift -= ppw;
 			end_mask = tab[(*src >> shift) & bit_mask];
 			FB_WRITEL((end_mask & eorx)^bgx, dst++);
-			if (!shift) { shift = 8; src++; }		
+			if (!shift) { shift = 8; src++; }
 		}
 		dst1 += p->fix.line_length;
 		s += spitch;
 	}
-}	
-	
+}
+
 void cfb_imageblit(struct fb_info *p, const struct fb_image *image)
 {
 	u32 fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
@@ -292,13 +292,13 @@ void cfb_imageblit(struct fb_info *p, const struct fb_image *image)
 		} else {
 			fgcolor = image->fg_color;
 			bgcolor = image->bg_color;
-		}	
-		
-		if (32 % bpp == 0 && !start_index && !pitch_index && 
+		}
+
+		if (32 % bpp == 0 && !start_index && !pitch_index &&
 		    ((width & (32/bpp-1)) == 0) &&
-		    bpp >= 8 && bpp <= 32) 			
+		    bpp >= 8 && bpp <= 32)
 			fast_imageblit(image, p, dst1, fgcolor, bgcolor);
-		else 
+		else
 			slow_imageblit(image, p, dst1, fgcolor, bgcolor,
 					start_index, pitch_index);
 	} else
-- 
2.35.1

[PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Thomas Zimmermann]

Improve the performance of cfb_imageblit() by manually unrolling
the inner blitting loop and moving some invariants out. The compiler
failed to do this automatically. This change keeps cfb_imageblit()
in sync with sys_imagebit().

A microbenchmark measures the average number of CPU cycles
for cfb_imageblit() after a stabilizing period of a few minutes
(i7-4790, FullHD, simpledrm, kernel with debugging).

cfb_imageblit(), new: 15724 cycles
cfb_imageblit(): old: 30566 cycles

In the optimized case, cfb_imageblit() is now ~2x faster than before.

v3:
	* fix commit description (Pekka)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/video/fbdev/core/cfbimgblt.c | 51 +++++++++++++++++++++++-----
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/core/cfbimgblt.c b/drivers/video/fbdev/core/cfbimgblt.c
index 01b01a279681..7361cfabdd85 100644
--- a/drivers/video/fbdev/core/cfbimgblt.c
+++ b/drivers/video/fbdev/core/cfbimgblt.c
@@ -218,23 +218,29 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
 {
 	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
 	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
-	u32 bit_mask, end_mask, eorx, shift;
+	u32 bit_mask, eorx;
 	const char *s = image->data, *src;
 	u32 __iomem *dst;
 	const u32 *tab = NULL;
+	size_t tablen;
+	u32 colortab[16];
 	int i, j, k;
 
 	switch (bpp) {
 	case 8:
 		tab = fb_be_math(p) ? cfb_tab8_be : cfb_tab8_le;
+		tablen = 16;
 		break;
 	case 16:
 		tab = fb_be_math(p) ? cfb_tab16_be : cfb_tab16_le;
+		tablen = 4;
 		break;
 	case 32:
-	default:
 		tab = cfb_tab32;
+		tablen = 2;
 		break;
+	default:
+		return;
 	}
 
 	for (i = ppw-1; i--; ) {
@@ -248,15 +254,42 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
 	eorx = fgx ^ bgx;
 	k = image->width/ppw;
 
-	for (i = image->height; i--; ) {
-		dst = (u32 __iomem *) dst1, shift = 8; src = s;
+	for (i = 0; i < tablen; ++i)
+		colortab[i] = (tab[i] & eorx) ^ bgx;
 
-		for (j = k; j--; ) {
-			shift -= ppw;
-			end_mask = tab[(*src >> shift) & bit_mask];
-			FB_WRITEL((end_mask & eorx)^bgx, dst++);
-			if (!shift) { shift = 8; src++; }
+	for (i = image->height; i--; ) {
+		dst = (u32 __iomem *)dst1;
+		src = s;
+
+		switch (ppw) {
+		case 4: /* 8 bpp */
+			for (j = k; j; j -= 2, ++src) {
+				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
+			}
+			break;
+		case 2: /* 16 bpp */
+			for (j = k; j; j -= 4, ++src) {
+				FB_WRITEL(colortab[(*src >> 6) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 2) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
+			}
+			break;
+		case 1: /* 32 bpp */
+			for (j = k; j; j -= 8, ++src) {
+				FB_WRITEL(colortab[(*src >> 7) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 6) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 5) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 3) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 2) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 1) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
+			}
+			break;
 		}
+
 		dst1 += p->fix.line_length;
 		s += spitch;
 	}
-- 
2.35.1

[PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Thomas Zimmermann]

Improve the performance of cfb_imageblit() by manually unrolling
the inner blitting loop and moving some invariants out. The compiler
failed to do this automatically. This change keeps cfb_imageblit()
in sync with sys_imagebit().

A microbenchmark measures the average number of CPU cycles
for cfb_imageblit() after a stabilizing period of a few minutes
(i7-4790, FullHD, simpledrm, kernel with debugging).

cfb_imageblit(), new: 15724 cycles
cfb_imageblit(): old: 30566 cycles

In the optimized case, cfb_imageblit() is now ~2x faster than before.

v3:
	* fix commit description (Pekka)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/video/fbdev/core/cfbimgblt.c | 51 +++++++++++++++++++++++-----
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/core/cfbimgblt.c b/drivers/video/fbdev/core/cfbimgblt.c
index 01b01a279681..7361cfabdd85 100644
--- a/drivers/video/fbdev/core/cfbimgblt.c
+++ b/drivers/video/fbdev/core/cfbimgblt.c
@@ -218,23 +218,29 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
 {
 	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
 	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
-	u32 bit_mask, end_mask, eorx, shift;
+	u32 bit_mask, eorx;
 	const char *s = image->data, *src;
 	u32 __iomem *dst;
 	const u32 *tab = NULL;
+	size_t tablen;
+	u32 colortab[16];
 	int i, j, k;
 
 	switch (bpp) {
 	case 8:
 		tab = fb_be_math(p) ? cfb_tab8_be : cfb_tab8_le;
+		tablen = 16;
 		break;
 	case 16:
 		tab = fb_be_math(p) ? cfb_tab16_be : cfb_tab16_le;
+		tablen = 4;
 		break;
 	case 32:
-	default:
 		tab = cfb_tab32;
+		tablen = 2;
 		break;
+	default:
+		return;
 	}
 
 	for (i = ppw-1; i--; ) {
@@ -248,15 +254,42 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
 	eorx = fgx ^ bgx;
 	k = image->width/ppw;
 
-	for (i = image->height; i--; ) {
-		dst = (u32 __iomem *) dst1, shift = 8; src = s;
+	for (i = 0; i < tablen; ++i)
+		colortab[i] = (tab[i] & eorx) ^ bgx;
 
-		for (j = k; j--; ) {
-			shift -= ppw;
-			end_mask = tab[(*src >> shift) & bit_mask];
-			FB_WRITEL((end_mask & eorx)^bgx, dst++);
-			if (!shift) { shift = 8; src++; }
+	for (i = image->height; i--; ) {
+		dst = (u32 __iomem *)dst1;
+		src = s;
+
+		switch (ppw) {
+		case 4: /* 8 bpp */
+			for (j = k; j; j -= 2, ++src) {
+				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
+			}
+			break;
+		case 2: /* 16 bpp */
+			for (j = k; j; j -= 4, ++src) {
+				FB_WRITEL(colortab[(*src >> 6) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 2) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
+			}
+			break;
+		case 1: /* 32 bpp */
+			for (j = k; j; j -= 8, ++src) {
+				FB_WRITEL(colortab[(*src >> 7) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 6) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 5) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 3) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 2) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 1) & bit_mask], dst++);
+				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
+			}
+			break;
 		}
+
 		dst1 += p->fix.line_length;
 		s += spitch;
 	}
-- 
2.35.1

[PATCH v3 5/5] drm: Add TODO item for optimizing format helpers

[Thomas Zimmermann]

Add a TODO item for optimizing blitting and format-conversion helpers
in DRM and fbdev. There's always demand for faster graphics output.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 Documentation/gpu/todo.rst | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 7bf7f2111696..7f113c6a02dd 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -241,6 +241,28 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter
 
 Level: Advanced
 
+Benchmark and optimize blitting and format-conversion function
+--------------------------------------------------------------
+
+Drawing to dispay memory quickly is crucial for many applications'
+performance.
+
+On at least x86-64, sys_imageblit() is significantly slower than
+cfb_imageblit(), even though both use the same blitting algorithm and
+the latter is written for I/O memory. It turns out that cfb_imageblit()
+uses movl instructions, while sys_imageblit apparently does not. This
+seems to be a problem with gcc's optimizer. DRM's format-conversion
+heleprs might be subject to similar issues.
+
+Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion
+helpers. In cases that can be further optimized, maybe implement a different
+algorithm, For micro-optimizations, use movl/movq instructions explicitly.
+That might possibly require architecture specific helpers (e.g., storel()
+storeq()).
+
+Contact: Thomas Zimmermann <tzimmermann@suse.de>
+
+Level: Intermediate
 
 drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
 -----------------------------------------------------------------
-- 
2.35.1

[PATCH v3 5/5] drm: Add TODO item for optimizing format helpers

[Thomas Zimmermann]

Add a TODO item for optimizing blitting and format-conversion helpers
in DRM and fbdev. There's always demand for faster graphics output.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 Documentation/gpu/todo.rst | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 7bf7f2111696..7f113c6a02dd 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -241,6 +241,28 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter
 
 Level: Advanced
 
+Benchmark and optimize blitting and format-conversion function
+--------------------------------------------------------------
+
+Drawing to dispay memory quickly is crucial for many applications'
+performance.
+
+On at least x86-64, sys_imageblit() is significantly slower than
+cfb_imageblit(), even though both use the same blitting algorithm and
+the latter is written for I/O memory. It turns out that cfb_imageblit()
+uses movl instructions, while sys_imageblit apparently does not. This
+seems to be a problem with gcc's optimizer. DRM's format-conversion
+heleprs might be subject to similar issues.
+
+Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion
+helpers. In cases that can be further optimized, maybe implement a different
+algorithm, For micro-optimizations, use movl/movq instructions explicitly.
+That might possibly require architecture specific helpers (e.g., storel()
+storeq()).
+
+Contact: Thomas Zimmermann <tzimmermann@suse.de>
+
+Level: Intermediate
 
 drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
 -----------------------------------------------------------------
-- 
2.35.1

Re: [PATCH v3 3/5] fbdev: Remove trailing whitespaces from cfbimgblt.c

[Sam Ravnborg]

On Wed, Feb 23, 2022 at 08:38:02PM +0100, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>

Re: [PATCH v3 3/5] fbdev: Remove trailing whitespaces from cfbimgblt.c

[Sam Ravnborg]

On Wed, Feb 23, 2022 at 08:38:02PM +0100, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Sam Ravnborg]

On Wed, Feb 23, 2022 at 08:38:03PM +0100, Thomas Zimmermann wrote:
> Improve the performance of cfb_imageblit() by manually unrolling
> the inner blitting loop and moving some invariants out. The compiler
> failed to do this automatically. This change keeps cfb_imageblit()
> in sync with sys_imagebit().
> 
> A microbenchmark measures the average number of CPU cycles
> for cfb_imageblit() after a stabilizing period of a few minutes
> (i7-4790, FullHD, simpledrm, kernel with debugging).
> 
> cfb_imageblit(), new: 15724 cycles
> cfb_imageblit(): old: 30566 cycles
> 
> In the optimized case, cfb_imageblit() is now ~2x faster than before.
> 
> v3:
> 	* fix commit description (Pekka)
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>

The code looks equally complicated now in the sys and cfb variants.

Question: What is cfb an abbreviation for anyway?
Not related to the patch - but if I have known the memory is lost..

	Sam

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Sam Ravnborg]

On Wed, Feb 23, 2022 at 08:38:03PM +0100, Thomas Zimmermann wrote:
> Improve the performance of cfb_imageblit() by manually unrolling
> the inner blitting loop and moving some invariants out. The compiler
> failed to do this automatically. This change keeps cfb_imageblit()
> in sync with sys_imagebit().
> 
> A microbenchmark measures the average number of CPU cycles
> for cfb_imageblit() after a stabilizing period of a few minutes
> (i7-4790, FullHD, simpledrm, kernel with debugging).
> 
> cfb_imageblit(), new: 15724 cycles
> cfb_imageblit(): old: 30566 cycles
> 
> In the optimized case, cfb_imageblit() is now ~2x faster than before.
> 
> v3:
> 	* fix commit description (Pekka)
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>

The code looks equally complicated now in the sys and cfb variants.

Question: What is cfb an abbreviation for anyway?
Not related to the patch - but if I have known the memory is lost..

	Sam

Re: [PATCH v3 5/5] drm: Add TODO item for optimizing format helpers

[Sam Ravnborg]

On Wed, Feb 23, 2022 at 08:38:04PM +0100, Thomas Zimmermann wrote:
> Add a TODO item for optimizing blitting and format-conversion helpers
> in DRM and fbdev. There's always demand for faster graphics output.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
>  Documentation/gpu/todo.rst | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 7bf7f2111696..7f113c6a02dd 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -241,6 +241,28 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter
>  
>  Level: Advanced
>  
> +Benchmark and optimize blitting and format-conversion function
> +--------------------------------------------------------------
> +
> +Drawing to dispay memory quickly is crucial for many applications'
              display
> +performance.
> +
> +On at least x86-64, sys_imageblit() is significantly slower than
   On, at least x86-64, ...
   To me the extra comma makes sense, but grammar is not my strong side.
 
> +cfb_imageblit(), even though both use the same blitting algorithm and
> +the latter is written for I/O memory. It turns out that cfb_imageblit()
> +uses movl instructions, while sys_imageblit apparently does not. This
> +seems to be a problem with gcc's optimizer. DRM's format-conversion
> +heleprs might be subject to similar issues.
   helpers
> +
> +Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion
> +helpers. In cases that can be further optimized, maybe implement a different
> +algorithm, For micro-optimizations, use movl/movq instructions explicitly.
   algorithm. (period, not comma)
> +That might possibly require architecture specific helpers (e.g., storel()
> +storeq()).
> +
> +Contact: Thomas Zimmermann <tzimmermann@suse.de>
> +
> +Level: Intermediate

With the small fixes above:
Acked-by: Sam Ravnborg <sam@ravnborg.org>

Another option would be to re-implement imageblit() to be drm specific.
Maybe we can then throw out some legacy code and optimize only for the drm
use. And then maybe only a small part of the code would differ if this
is I/O memory or direct accessible memory.

	Sam

Re: [PATCH v3 5/5] drm: Add TODO item for optimizing format helpers

[Sam Ravnborg]

On Wed, Feb 23, 2022 at 08:38:04PM +0100, Thomas Zimmermann wrote:
> Add a TODO item for optimizing blitting and format-conversion helpers
> in DRM and fbdev. There's always demand for faster graphics output.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
>  Documentation/gpu/todo.rst | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 7bf7f2111696..7f113c6a02dd 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -241,6 +241,28 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter
>  
>  Level: Advanced
>  
> +Benchmark and optimize blitting and format-conversion function
> +--------------------------------------------------------------
> +
> +Drawing to dispay memory quickly is crucial for many applications'
              display
> +performance.
> +
> +On at least x86-64, sys_imageblit() is significantly slower than
   On, at least x86-64, ...
   To me the extra comma makes sense, but grammar is not my strong side.
 
> +cfb_imageblit(), even though both use the same blitting algorithm and
> +the latter is written for I/O memory. It turns out that cfb_imageblit()
> +uses movl instructions, while sys_imageblit apparently does not. This
> +seems to be a problem with gcc's optimizer. DRM's format-conversion
> +heleprs might be subject to similar issues.
   helpers
> +
> +Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion
> +helpers. In cases that can be further optimized, maybe implement a different
> +algorithm, For micro-optimizations, use movl/movq instructions explicitly.
   algorithm. (period, not comma)
> +That might possibly require architecture specific helpers (e.g., storel()
> +storeq()).
> +
> +Contact: Thomas Zimmermann <tzimmermann@suse.de>
> +
> +Level: Intermediate

With the small fixes above:
Acked-by: Sam Ravnborg <sam@ravnborg.org>

Another option would be to re-implement imageblit() to be drm specific.
Maybe we can then throw out some legacy code and optimize only for the drm
use. And then maybe only a small part of the code would differ if this
is I/O memory or direct accessible memory.

	Sam

Re: [PATCH v3 3/5] fbdev: Remove trailing whitespaces from cfbimgblt.c

[Javier Martinez Canillas]

On 2/23/22 20:38, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v3 3/5] fbdev: Remove trailing whitespaces from cfbimgblt.c

[Javier Martinez Canillas]

On 2/23/22 20:38, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Javier Martinez Canillas]

On 2/23/22 20:38, Thomas Zimmermann wrote:
> Improve the performance of cfb_imageblit() by manually unrolling
> the inner blitting loop and moving some invariants out. The compiler
> failed to do this automatically. This change keeps cfb_imageblit()
> in sync with sys_imagebit().
> 
> A microbenchmark measures the average number of CPU cycles
> for cfb_imageblit() after a stabilizing period of a few minutes
> (i7-4790, FullHD, simpledrm, kernel with debugging).
> 
> cfb_imageblit(), new: 15724 cycles
> cfb_imageblit(): old: 30566 cycles
> 
> In the optimized case, cfb_imageblit() is now ~2x faster than before.
> 
> v3:
> 	* fix commit description (Pekka)
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---

Makes sense, improves perf and makes the two more consistent as you mention.

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Javier Martinez Canillas]

On 2/23/22 20:38, Thomas Zimmermann wrote:
> Improve the performance of cfb_imageblit() by manually unrolling
> the inner blitting loop and moving some invariants out. The compiler
> failed to do this automatically. This change keeps cfb_imageblit()
> in sync with sys_imagebit().
> 
> A microbenchmark measures the average number of CPU cycles
> for cfb_imageblit() after a stabilizing period of a few minutes
> (i7-4790, FullHD, simpledrm, kernel with debugging).
> 
> cfb_imageblit(), new: 15724 cycles
> cfb_imageblit(): old: 30566 cycles
> 
> In the optimized case, cfb_imageblit() is now ~2x faster than before.
> 
> v3:
> 	* fix commit description (Pekka)
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---

Makes sense, improves perf and makes the two more consistent as you mention.

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v3 5/5] drm: Add TODO item for optimizing format helpers

[Javier Martinez Canillas]

On 2/23/22 20:38, Thomas Zimmermann wrote:
> Add a TODO item for optimizing blitting and format-conversion helpers
> in DRM and fbdev. There's always demand for faster graphics output.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---

After fixing the typos mentioned by Sam:

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v3 5/5] drm: Add TODO item for optimizing format helpers

[Javier Martinez Canillas]

On 2/23/22 20:38, Thomas Zimmermann wrote:
> Add a TODO item for optimizing blitting and format-conversion helpers
> in DRM and fbdev. There's always demand for faster graphics output.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---

After fixing the typos mentioned by Sam:

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Javier Martinez Canillas]

Hello Sam,

On 2/23/22 21:25, Sam Ravnborg wrote:

[snip]

> 
> Question: What is cfb an abbreviation for anyway?
> Not related to the patch - but if I have known the memory is lost..
> 

I was curious so I dug on this. It seems CFB stands for Color Frame Buffer.
Doing a `git grep "(CFB)"` in the linux history repo [0], I get this:

  Documentation/isdn/README.diversion:   (CFB). 
  drivers/video/pmag-ba-fb.c: *   PMAG-BA TURBOchannel Color Frame Buffer (CFB) card support,
  include/video/pmag-ba-fb.h: *   TURBOchannel PMAG-BA Color Frame Buffer (CFB) card support,

Probably the helpers are called like this because they were for any fbdev
driver but assumed that the framebuffer was always in I/O memory. Later some
drivers were allocating the framebuffer in system memory and still using the
helpers, that were using I/O memory accessors and it's ilegal on some arches.

So the sys_* variants where introduced by commit 68648ed1f58d ("fbdev: add
drawing functions for framebuffers in system RAM") to fix this. The old
ones just kept their name, but probably it should had been renamed to io_*
for the naming to be consistent with the sys_* functions.

[0]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Javier Martinez Canillas]

Hello Sam,

On 2/23/22 21:25, Sam Ravnborg wrote:

[snip]

> 
> Question: What is cfb an abbreviation for anyway?
> Not related to the patch - but if I have known the memory is lost..
> 

I was curious so I dug on this. It seems CFB stands for Color Frame Buffer.
Doing a `git grep "(CFB)"` in the linux history repo [0], I get this:

  Documentation/isdn/README.diversion:   (CFB). 
  drivers/video/pmag-ba-fb.c: *   PMAG-BA TURBOchannel Color Frame Buffer (CFB) card support,
  include/video/pmag-ba-fb.h: *   TURBOchannel PMAG-BA Color Frame Buffer (CFB) card support,

Probably the helpers are called like this because they were for any fbdev
driver but assumed that the framebuffer was always in I/O memory. Later some
drivers were allocating the framebuffer in system memory and still using the
helpers, that were using I/O memory accessors and it's ilegal on some arches.

So the sys_* variants where introduced by commit 68648ed1f58d ("fbdev: add
drawing functions for framebuffers in system RAM") to fix this. The old
ones just kept their name, but probably it should had been renamed to io_*
for the naming to be consistent with the sys_* functions.

[0]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Sam Ravnborg]

Hi Javier,
On Thu, Feb 24, 2022 at 10:02:59AM +0100, Javier Martinez Canillas wrote:
> Hello Sam,
> 
> On 2/23/22 21:25, Sam Ravnborg wrote:
> 
> [snip]
> 
> > 
> > Question: What is cfb an abbreviation for anyway?
> > Not related to the patch - but if I have known the memory is lost..
> > 
> 
> I was curious so I dug on this. It seems CFB stands for Color Frame Buffer.
> Doing a `git grep "(CFB)"` in the linux history repo [0], I get this:
> 
>   Documentation/isdn/README.diversion:   (CFB). 
>   drivers/video/pmag-ba-fb.c: *   PMAG-BA TURBOchannel Color Frame Buffer (CFB) card support,
>   include/video/pmag-ba-fb.h: *   TURBOchannel PMAG-BA Color Frame Buffer (CFB) card support,
> 
> Probably the helpers are called like this because they were for any fbdev
> driver but assumed that the framebuffer was always in I/O memory. Later some
> drivers were allocating the framebuffer in system memory and still using the
> helpers, that were using I/O memory accessors and it's ilegal on some arches.
> 
> So the sys_* variants where introduced by commit 68648ed1f58d ("fbdev: add
> drawing functions for framebuffers in system RAM") to fix this. The old
> ones just kept their name, but probably it should had been renamed to io_*
> for the naming to be consistent with the sys_* functions.
> 
> [0]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/

Interesting - thanks for the history lesson and thanks for taking your
time to share your findings too.

	Sam

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Sam Ravnborg]

Hi Javier,
On Thu, Feb 24, 2022 at 10:02:59AM +0100, Javier Martinez Canillas wrote:
> Hello Sam,
> 
> On 2/23/22 21:25, Sam Ravnborg wrote:
> 
> [snip]
> 
> > 
> > Question: What is cfb an abbreviation for anyway?
> > Not related to the patch - but if I have known the memory is lost..
> > 
> 
> I was curious so I dug on this. It seems CFB stands for Color Frame Buffer.
> Doing a `git grep "(CFB)"` in the linux history repo [0], I get this:
> 
>   Documentation/isdn/README.diversion:   (CFB). 
>   drivers/video/pmag-ba-fb.c: *   PMAG-BA TURBOchannel Color Frame Buffer (CFB) card support,
>   include/video/pmag-ba-fb.h: *   TURBOchannel PMAG-BA Color Frame Buffer (CFB) card support,
> 
> Probably the helpers are called like this because they were for any fbdev
> driver but assumed that the framebuffer was always in I/O memory. Later some
> drivers were allocating the framebuffer in system memory and still using the
> helpers, that were using I/O memory accessors and it's ilegal on some arches.
> 
> So the sys_* variants where introduced by commit 68648ed1f58d ("fbdev: add
> drawing functions for framebuffers in system RAM") to fix this. The old
> ones just kept their name, but probably it should had been renamed to io_*
> for the naming to be consistent with the sys_* functions.
> 
> [0]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/

Interesting - thanks for the history lesson and thanks for taking your
time to share your findings too.

	Sam

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Geert Uytterhoeven]

Hi Javier,

On Thu, Feb 24, 2022 at 10:03 AM Javier Martinez Canillas
<javierm@redhat.com> wrote:
> On 2/23/22 21:25, Sam Ravnborg wrote:
> > Question: What is cfb an abbreviation for anyway?
> > Not related to the patch - but if I have known the memory is lost..
>
> I was curious so I dug on this. It seems CFB stands for Color Frame Buffer.
> Doing a `git grep "(CFB)"` in the linux history repo [0], I get this:

The naming actually comes from X11.
"mfb" is a monochrome frame buffer (bpp = 1).
"cfb" is a color frame buffer (bpp > 1), which uses a chunky format.

> Probably the helpers are called like this because they were for any fbdev
> driver but assumed that the framebuffer was always in I/O memory. Later some
> drivers were allocating the framebuffer in system memory and still using the
> helpers, that were using I/O memory accessors and it's ilegal on some arches.

Yep.  Graphics memory used to be on a graphics card.
On systems (usually non-x86) where it was part of main memory, usually
it didn't matter at all whether you used I/O memory or plain memory
accessors anyway.

Then x86 got unified memory...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Geert Uytterhoeven]

Hi Javier,

On Thu, Feb 24, 2022 at 10:03 AM Javier Martinez Canillas
<javierm@redhat.com> wrote:
> On 2/23/22 21:25, Sam Ravnborg wrote:
> > Question: What is cfb an abbreviation for anyway?
> > Not related to the patch - but if I have known the memory is lost..
>
> I was curious so I dug on this. It seems CFB stands for Color Frame Buffer.
> Doing a `git grep "(CFB)"` in the linux history repo [0], I get this:

The naming actually comes from X11.
"mfb" is a monochrome frame buffer (bpp = 1).
"cfb" is a color frame buffer (bpp > 1), which uses a chunky format.

> Probably the helpers are called like this because they were for any fbdev
> driver but assumed that the framebuffer was always in I/O memory. Later some
> drivers were allocating the framebuffer in system memory and still using the
> helpers, that were using I/O memory accessors and it's ilegal on some arches.

Yep.  Graphics memory used to be on a graphics card.
On systems (usually non-x86) where it was part of main memory, usually
it didn't matter at all whether you used I/O memory or plain memory
accessors anyway.

Then x86 got unified memory...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v3 0/5] fbdev: Improve performance of fbdev console

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2276 bytes --]

Hi,

merged with fixes for the typoes in the final patch. Thanks for reviewing.

Best regards
Thomas

Am 23.02.22 um 20:37 schrieb Thomas Zimmermann:
> Optimize performance of the fbdev console for the common case of
> software-based clearing and image blitting.
> 
> The commit descripton of each patch contains resuls os a simple
> microbenchmark. I also tested the full patchset's effect on the
> console output by printing directory listings (i7-4790, FullHD,
> simpledrm, kernel with debugging).
> 
>    > time find /usr/share/doc -type f
> 
> In the unoptimized case:
> 
>    real    0m6.173s
>    user    0m0.044s
>    sys     0m6.107s
> 
> With optimizations applied:
> 
>    real    0m4.754s
>    user    0m0.044s
>    sys     0m4.698s
> 
> In the optimized case, printing the directory listing is ~25% faster
> than before.
> 
> In v2 of the patchset, after implementing Sam's suggestion to update
> cfb_imageblit() as well, it turns out that the compiled code in
> sys_imageblit() is still significantly slower than the CFB version. A
> fix is probably a larger task and would include architecture-specific
> changes. A new TODO item suggests to investigate the performance of the
> various helpers and format-conversion functions in DRM and fbdev.
> 
> v3:
> 	* fix description of cfb_imageblit() patch (Pekka)
> v2:
> 	* improve readability for sys_imageblit() (Gerd, Sam)
> 	* new TODO item for further optimization
> 
> Thomas Zimmermann (5):
>    fbdev: Improve performance of sys_fillrect()
>    fbdev: Improve performance of sys_imageblit()
>    fbdev: Remove trailing whitespaces from cfbimgblt.c
>    fbdev: Improve performance of cfb_imageblit()
>    drm: Add TODO item for optimizing format helpers
> 
>   Documentation/gpu/todo.rst             |  22 +++++
>   drivers/video/fbdev/core/cfbimgblt.c   | 107 ++++++++++++++++---------
>   drivers/video/fbdev/core/sysfillrect.c |  16 +---
>   drivers/video/fbdev/core/sysimgblt.c   |  49 ++++++++---
>   4 files changed, 133 insertions(+), 61 deletions(-)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v3 0/5] fbdev: Improve performance of fbdev console

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 2276 bytes --]

Hi,

merged with fixes for the typoes in the final patch. Thanks for reviewing.

Best regards
Thomas

Am 23.02.22 um 20:37 schrieb Thomas Zimmermann:
> Optimize performance of the fbdev console for the common case of
> software-based clearing and image blitting.
> 
> The commit descripton of each patch contains resuls os a simple
> microbenchmark. I also tested the full patchset's effect on the
> console output by printing directory listings (i7-4790, FullHD,
> simpledrm, kernel with debugging).
> 
>    > time find /usr/share/doc -type f
> 
> In the unoptimized case:
> 
>    real    0m6.173s
>    user    0m0.044s
>    sys     0m6.107s
> 
> With optimizations applied:
> 
>    real    0m4.754s
>    user    0m0.044s
>    sys     0m4.698s
> 
> In the optimized case, printing the directory listing is ~25% faster
> than before.
> 
> In v2 of the patchset, after implementing Sam's suggestion to update
> cfb_imageblit() as well, it turns out that the compiled code in
> sys_imageblit() is still significantly slower than the CFB version. A
> fix is probably a larger task and would include architecture-specific
> changes. A new TODO item suggests to investigate the performance of the
> various helpers and format-conversion functions in DRM and fbdev.
> 
> v3:
> 	* fix description of cfb_imageblit() patch (Pekka)
> v2:
> 	* improve readability for sys_imageblit() (Gerd, Sam)
> 	* new TODO item for further optimization
> 
> Thomas Zimmermann (5):
>    fbdev: Improve performance of sys_fillrect()
>    fbdev: Improve performance of sys_imageblit()
>    fbdev: Remove trailing whitespaces from cfbimgblt.c
>    fbdev: Improve performance of cfb_imageblit()
>    drm: Add TODO item for optimizing format helpers
> 
>   Documentation/gpu/todo.rst             |  22 +++++
>   drivers/video/fbdev/core/cfbimgblt.c   | 107 ++++++++++++++++---------
>   drivers/video/fbdev/core/sysfillrect.c |  16 +---
>   drivers/video/fbdev/core/sysimgblt.c   |  49 ++++++++---
>   4 files changed, 133 insertions(+), 61 deletions(-)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Marek Szyprowski]

Hi Thomas,

On 23.02.2022 20:38, Thomas Zimmermann wrote:
> Improve the performance of cfb_imageblit() by manually unrolling
> the inner blitting loop and moving some invariants out. The compiler
> failed to do this automatically. This change keeps cfb_imageblit()
> in sync with sys_imagebit().
>
> A microbenchmark measures the average number of CPU cycles
> for cfb_imageblit() after a stabilizing period of a few minutes
> (i7-4790, FullHD, simpledrm, kernel with debugging).
>
> cfb_imageblit(), new: 15724 cycles
> cfb_imageblit(): old: 30566 cycles
>
> In the optimized case, cfb_imageblit() is now ~2x faster than before.
>
> v3:
> 	* fix commit description (Pekka)
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
This patch landed recently in linux next-20220308 as commit 0d03011894d2 
("fbdev: Improve performance of cfb_imageblit()"). Sadly it causes a 
freeze after DRM and emulated fbdev initialization on various Samsung 
Exynos ARM 32bit based boards. This happens when kernel is compiled from 
exynos_defconfig. Surprisingly when kernel is compiled from 
multi_v7_defconfig all those boards boot fine, so this is a matter of 
one of the debugging options enabled in the exynos_defconfig. I will try 
to analyze this further and share the results. Reverting $subject on top 
of next-20220308 fixes the boot issue.
> ---
>   drivers/video/fbdev/core/cfbimgblt.c | 51 +++++++++++++++++++++++-----
>   1 file changed, 42 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/cfbimgblt.c b/drivers/video/fbdev/core/cfbimgblt.c
> index 01b01a279681..7361cfabdd85 100644
> --- a/drivers/video/fbdev/core/cfbimgblt.c
> +++ b/drivers/video/fbdev/core/cfbimgblt.c
> @@ -218,23 +218,29 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
>   {
>   	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
>   	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
> -	u32 bit_mask, end_mask, eorx, shift;
> +	u32 bit_mask, eorx;
>   	const char *s = image->data, *src;
>   	u32 __iomem *dst;
>   	const u32 *tab = NULL;
> +	size_t tablen;
> +	u32 colortab[16];
>   	int i, j, k;
>   
>   	switch (bpp) {
>   	case 8:
>   		tab = fb_be_math(p) ? cfb_tab8_be : cfb_tab8_le;
> +		tablen = 16;
>   		break;
>   	case 16:
>   		tab = fb_be_math(p) ? cfb_tab16_be : cfb_tab16_le;
> +		tablen = 4;
>   		break;
>   	case 32:
> -	default:
>   		tab = cfb_tab32;
> +		tablen = 2;
>   		break;
> +	default:
> +		return;
>   	}
>   
>   	for (i = ppw-1; i--; ) {
> @@ -248,15 +254,42 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
>   	eorx = fgx ^ bgx;
>   	k = image->width/ppw;
>   
> -	for (i = image->height; i--; ) {
> -		dst = (u32 __iomem *) dst1, shift = 8; src = s;
> +	for (i = 0; i < tablen; ++i)
> +		colortab[i] = (tab[i] & eorx) ^ bgx;
>   
> -		for (j = k; j--; ) {
> -			shift -= ppw;
> -			end_mask = tab[(*src >> shift) & bit_mask];
> -			FB_WRITEL((end_mask & eorx)^bgx, dst++);
> -			if (!shift) { shift = 8; src++; }
> +	for (i = image->height; i--; ) {
> +		dst = (u32 __iomem *)dst1;
> +		src = s;
> +
> +		switch (ppw) {
> +		case 4: /* 8 bpp */
> +			for (j = k; j; j -= 2, ++src) {
> +				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
> +			}
> +			break;
> +		case 2: /* 16 bpp */
> +			for (j = k; j; j -= 4, ++src) {
> +				FB_WRITEL(colortab[(*src >> 6) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 2) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
> +			}
> +			break;
> +		case 1: /* 32 bpp */
> +			for (j = k; j; j -= 8, ++src) {
> +				FB_WRITEL(colortab[(*src >> 7) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 6) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 5) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 3) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 2) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 1) & bit_mask], dst++);
> +				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
> +			}
> +			break;
>   		}
> +
>   		dst1 += p->fix.line_length;
>   		s += spitch;
>   	}

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 5244 bytes --]

Hi

Am 08.03.22 um 23:52 schrieb Marek Szyprowski:
> Hi Thomas,
> 
> On 23.02.2022 20:38, Thomas Zimmermann wrote:
>> Improve the performance of cfb_imageblit() by manually unrolling
>> the inner blitting loop and moving some invariants out. The compiler
>> failed to do this automatically. This change keeps cfb_imageblit()
>> in sync with sys_imagebit().
>>
>> A microbenchmark measures the average number of CPU cycles
>> for cfb_imageblit() after a stabilizing period of a few minutes
>> (i7-4790, FullHD, simpledrm, kernel with debugging).
>>
>> cfb_imageblit(), new: 15724 cycles
>> cfb_imageblit(): old: 30566 cycles
>>
>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
>>
>> v3:
>> 	* fix commit description (Pekka)
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> This patch landed recently in linux next-20220308 as commit 0d03011894d2
> ("fbdev: Improve performance of cfb_imageblit()"). Sadly it causes a
> freeze after DRM and emulated fbdev initialization on various Samsung
> Exynos ARM 32bit based boards. This happens when kernel is compiled from
> exynos_defconfig. Surprisingly when kernel is compiled from
> multi_v7_defconfig all those boards boot fine, so this is a matter of
> one of the debugging options enabled in the exynos_defconfig. I will try
> to analyze this further and share the results. Reverting $subject on top
> of next-20220308 fixes the boot issue.

Thanks for reporting. I don't have the hardware to reproduce it and 
there's no obvious difference to the original version. It's supposed to 
be the same algorithm with a different implementation. Unless you can 
figure out the issue, we can also revert the patch easily.

Best regards
Thomas

>> ---
>>    drivers/video/fbdev/core/cfbimgblt.c | 51 +++++++++++++++++++++++-----
>>    1 file changed, 42 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/core/cfbimgblt.c b/drivers/video/fbdev/core/cfbimgblt.c
>> index 01b01a279681..7361cfabdd85 100644
>> --- a/drivers/video/fbdev/core/cfbimgblt.c
>> +++ b/drivers/video/fbdev/core/cfbimgblt.c
>> @@ -218,23 +218,29 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
>>    {
>>    	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
>>    	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
>> -	u32 bit_mask, end_mask, eorx, shift;
>> +	u32 bit_mask, eorx;
>>    	const char *s = image->data, *src;
>>    	u32 __iomem *dst;
>>    	const u32 *tab = NULL;
>> +	size_t tablen;
>> +	u32 colortab[16];
>>    	int i, j, k;
>>    
>>    	switch (bpp) {
>>    	case 8:
>>    		tab = fb_be_math(p) ? cfb_tab8_be : cfb_tab8_le;
>> +		tablen = 16;
>>    		break;
>>    	case 16:
>>    		tab = fb_be_math(p) ? cfb_tab16_be : cfb_tab16_le;
>> +		tablen = 4;
>>    		break;
>>    	case 32:
>> -	default:
>>    		tab = cfb_tab32;
>> +		tablen = 2;
>>    		break;
>> +	default:
>> +		return;
>>    	}
>>    
>>    	for (i = ppw-1; i--; ) {
>> @@ -248,15 +254,42 @@ static inline void fast_imageblit(const struct fb_image *image, struct fb_info *
>>    	eorx = fgx ^ bgx;
>>    	k = image->width/ppw;
>>    
>> -	for (i = image->height; i--; ) {
>> -		dst = (u32 __iomem *) dst1, shift = 8; src = s;
>> +	for (i = 0; i < tablen; ++i)
>> +		colortab[i] = (tab[i] & eorx) ^ bgx;
>>    
>> -		for (j = k; j--; ) {
>> -			shift -= ppw;
>> -			end_mask = tab[(*src >> shift) & bit_mask];
>> -			FB_WRITEL((end_mask & eorx)^bgx, dst++);
>> -			if (!shift) { shift = 8; src++; }
>> +	for (i = image->height; i--; ) {
>> +		dst = (u32 __iomem *)dst1;
>> +		src = s;
>> +
>> +		switch (ppw) {
>> +		case 4: /* 8 bpp */
>> +			for (j = k; j; j -= 2, ++src) {
>> +				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
>> +			}
>> +			break;
>> +		case 2: /* 16 bpp */
>> +			for (j = k; j; j -= 4, ++src) {
>> +				FB_WRITEL(colortab[(*src >> 6) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 2) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
>> +			}
>> +			break;
>> +		case 1: /* 32 bpp */
>> +			for (j = k; j; j -= 8, ++src) {
>> +				FB_WRITEL(colortab[(*src >> 7) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 6) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 5) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 4) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 3) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 2) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 1) & bit_mask], dst++);
>> +				FB_WRITEL(colortab[(*src >> 0) & bit_mask], dst++);
>> +			}
>> +			break;
>>    		}
>> +
>>    		dst1 += p->fix.line_length;
>>    		s += spitch;
>>    	}
> 
> Best regards

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Marek Szyprowski]

Hi,

On 09.03.2022 09:22, Thomas Zimmermann wrote:
> Am 08.03.22 um 23:52 schrieb Marek Szyprowski:
>> On 23.02.2022 20:38, Thomas Zimmermann wrote:
>>> Improve the performance of cfb_imageblit() by manually unrolling
>>> the inner blitting loop and moving some invariants out. The compiler
>>> failed to do this automatically. This change keeps cfb_imageblit()
>>> in sync with sys_imagebit().
>>>
>>> A microbenchmark measures the average number of CPU cycles
>>> for cfb_imageblit() after a stabilizing period of a few minutes
>>> (i7-4790, FullHD, simpledrm, kernel with debugging).
>>>
>>> cfb_imageblit(), new: 15724 cycles
>>> cfb_imageblit(): old: 30566 cycles
>>>
>>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
>>>
>>> v3:
>>>     * fix commit description (Pekka)
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>> This patch landed recently in linux next-20220308 as commit 0d03011894d2
>> ("fbdev: Improve performance of cfb_imageblit()"). Sadly it causes a
>> freeze after DRM and emulated fbdev initialization on various Samsung
>> Exynos ARM 32bit based boards. This happens when kernel is compiled from
>> exynos_defconfig. Surprisingly when kernel is compiled from
>> multi_v7_defconfig all those boards boot fine, so this is a matter of
>> one of the debugging options enabled in the exynos_defconfig. I will try
>> to analyze this further and share the results. Reverting $subject on top
>> of next-20220308 fixes the boot issue.
>
> Thanks for reporting. I don't have the hardware to reproduce it and 
> there's no obvious difference to the original version. It's supposed 
> to be the same algorithm with a different implementation. Unless you 
> can figure out the issue, we can also revert the patch easily.

I've played a bit with .config options and found that the issue is 
caused by the compiled-in fonts used for the framebuffer. For some 
reasons (so far unknown to me), exynos_defconfig has the following odd 
setup:

CONFIG_FONT_SUPPORT=y
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
# CONFIG_FONT_6x11 is not set
CONFIG_FONT_7x14=y
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_6x10 is not set
# CONFIG_FONT_10x18 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_TER16x32 is not set
# CONFIG_FONT_6x8 is not set

Such setup causes a freeze during framebuffer initialization (or just 
after it got registered). I've reproduced this even on Raspberry Pi 3B 
with multi_v7_defconfig and changed fonts configuration (this also 
required to disable vivid driver, which forces 8x16 font), where I got 
the following panic:

simple-framebuffer 3eace000.framebuffer: framebuffer at 0x3eace000, 
0x12c000 bytes
simple-framebuffer 3eace000.framebuffer: format=a8r8g8b8, 
mode=640x480x32, linelength=2560
8<--- cut here ---
Unable to handle kernel paging request at virtual address f0aac000
[f0aac000] *pgd=01d8b811, *pte=00000000, *ppte=00000000
Internal error: Oops: 807 [#1] SMP ARM
Modules linked in:
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 
5.17.0-rc7-next-20220308-00002-g9e9894c98f8c #11471
Hardware name: BCM2835
PC is at cfb_imageblit+0x52c/0x64c
LR is at 0x1
pc : [<c0603dd8>]    lr : [<00000001>]    psr: a0000013
sp : f081da68  ip : c1d5ffff  fp : f081dad8
r10: f0980000  r9 : c1d69600  r8 : fffb5007
r7 : 00000000  r6 : 00000001  r5 : 00000a00  r4 : 00000001
r3 : 00000055  r2 : f0aac000  r1 : f081dad8  r0 : 00000007
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5383d  Table: 0000406a  DAC: 00000051
Register r0 information: non-paged memory
Register r1 information: 2-page vmalloc region starting at 0xf081c000 
allocated at kernel_clone+0xc0/0x428
Register r2 information: 0-page vmalloc region starting at 0xf0980000 
allocated at simplefb_probe+0x284/0x9b0
Register r3 information: non-paged memory
Register r4 information: non-paged memory
Register r5 information: non-paged memory
Register r6 information: non-paged memory
Register r7 information: NULL pointer
Register r8 information: non-paged memory
Register r9 information: non-slab/vmalloc memory
Register r10 information: 0-page vmalloc region starting at 0xf0980000 
allocated at simplefb_probe+0x284/0x9b0
Register r11 information: 2-page vmalloc region starting at 0xf081c000 
allocated at kernel_clone+0xc0/0x428
Register r12 information: non-slab/vmalloc memory
Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
Stack: (0xf081da68 to 0xf081e000)
...
  cfb_imageblit from soft_cursor+0x164/0x1cc
  soft_cursor from bit_cursor+0x4c0/0x4fc
  bit_cursor from fbcon_cursor+0xf8/0x108
  fbcon_cursor from hide_cursor+0x34/0x94
  hide_cursor from redraw_screen+0x13c/0x22c
  redraw_screen from fbcon_prepare_logo+0x164/0x444
  fbcon_prepare_logo from fbcon_init+0x38c/0x4bc
  fbcon_init from visual_init+0xc0/0x108
  visual_init from do_bind_con_driver+0x1ac/0x38c
  do_bind_con_driver from do_take_over_console+0x13c/0x1c8
  do_take_over_console from do_fbcon_takeover+0x74/0xcc
  do_fbcon_takeover from register_framebuffer+0x1bc/0x2cc
  register_framebuffer from simplefb_probe+0x8dc/0x9b0
  simplefb_probe from platform_probe+0x80/0xc0
  platform_probe from really_probe+0xc0/0x304
  really_probe from __driver_probe_device+0x88/0xe0
  __driver_probe_device from driver_probe_device+0x34/0xd4
  driver_probe_device from __driver_attach+0x8c/0xe0
  __driver_attach from bus_for_each_dev+0x64/0xb0
  bus_for_each_dev from bus_add_driver+0x160/0x1e4
  bus_add_driver from driver_register+0x78/0x10c
  driver_register from do_one_initcall+0x44/0x1e0
  do_one_initcall from kernel_init_freeable+0x1bc/0x20c
  kernel_init_freeable from kernel_init+0x18/0x12c
  kernel_init from ret_from_fork+0x14/0x2c
Code: e28db070 e00473a3 e08b7107 e5177044 (e5827000)
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU0: stopping
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G      D 
5.17.0-rc7-next-20220308-00002-g9e9894c98f8c #11471
Hardware name: BCM2835
  unwind_backtrace from show_stack+0x10/0x14
  show_stack from 0xc1201e64
CPU2: stopping
CPU: 2 PID: 0 Comm: swapper/2 Tainted: G      D 
5.17.0-rc7-next-20220308-00002-g9e9894c98f8c #11471
Hardware name: BCM2835
  unwind_backtrace from show_stack+0x10/0x14
  show_stack from 0xf0809f5c
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D 
5.17.0-rc7-next-20220308-00002-g9e9894c98f8c #11471
Hardware name: BCM2835
  unwind_backtrace from show_stack+0x10/0x14
  show_stack from 0xf0805f5c
---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0000000b ]---

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Geert Uytterhoeven]

Hi Marek,

On Wed, Mar 9, 2022 at 10:22 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> On 09.03.2022 09:22, Thomas Zimmermann wrote:
> > Am 08.03.22 um 23:52 schrieb Marek Szyprowski:
> >> On 23.02.2022 20:38, Thomas Zimmermann wrote:
> >>> Improve the performance of cfb_imageblit() by manually unrolling
> >>> the inner blitting loop and moving some invariants out. The compiler
> >>> failed to do this automatically. This change keeps cfb_imageblit()
> >>> in sync with sys_imagebit().
> >>>
> >>> A microbenchmark measures the average number of CPU cycles
> >>> for cfb_imageblit() after a stabilizing period of a few minutes
> >>> (i7-4790, FullHD, simpledrm, kernel with debugging).
> >>>
> >>> cfb_imageblit(), new: 15724 cycles
> >>> cfb_imageblit(): old: 30566 cycles
> >>>
> >>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
> >>>
> >>> v3:
> >>>     * fix commit description (Pekka)
> >>>
> >>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> >>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> >>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> >> This patch landed recently in linux next-20220308 as commit 0d03011894d2
> >> ("fbdev: Improve performance of cfb_imageblit()"). Sadly it causes a
> >> freeze after DRM and emulated fbdev initialization on various Samsung
> >> Exynos ARM 32bit based boards. This happens when kernel is compiled from
> >> exynos_defconfig. Surprisingly when kernel is compiled from
> >> multi_v7_defconfig all those boards boot fine, so this is a matter of
> >> one of the debugging options enabled in the exynos_defconfig. I will try
> >> to analyze this further and share the results. Reverting $subject on top
> >> of next-20220308 fixes the boot issue.
> >
> > Thanks for reporting. I don't have the hardware to reproduce it and
> > there's no obvious difference to the original version. It's supposed
> > to be the same algorithm with a different implementation. Unless you
> > can figure out the issue, we can also revert the patch easily.
>
> I've played a bit with .config options and found that the issue is
> caused by the compiled-in fonts used for the framebuffer. For some
> reasons (so far unknown to me), exynos_defconfig has the following odd
> setup:
>
> CONFIG_FONT_SUPPORT=y
> CONFIG_FONTS=y
> # CONFIG_FONT_8x8 is not set
> # CONFIG_FONT_8x16 is not set
> # CONFIG_FONT_6x11 is not set
> CONFIG_FONT_7x14=y
> # CONFIG_FONT_PEARL_8x8 is not set
> # CONFIG_FONT_ACORN_8x8 is not set
> # CONFIG_FONT_MINI_4x6 is not set
> # CONFIG_FONT_6x10 is not set
> # CONFIG_FONT_10x18 is not set
> # CONFIG_FONT_SUN8x16 is not set
> # CONFIG_FONT_SUN12x22 is not set
> # CONFIG_FONT_TER16x32 is not set
> # CONFIG_FONT_6x8 is not set
>
> Such setup causes a freeze during framebuffer initialization (or just
> after it got registered). I've reproduced this even on Raspberry Pi 3B
> with multi_v7_defconfig and changed fonts configuration (this also
> required to disable vivid driver, which forces 8x16 font), where I got
> the following panic:
>
> simple-framebuffer 3eace000.framebuffer: framebuffer at 0x3eace000,
> 0x12c000 bytes
> simple-framebuffer 3eace000.framebuffer: format=a8r8g8b8,
> mode=640x480x32, linelength=2560
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address f0aac000

So support for images with offsets or widths that are not a multiple
of 8 got broken in cfb_imageblit(). Oops...

BTW, the various drawing routines used to set a bitmask indicating
which alignments were supported (see blit_x), but most of them no
longer do, presumably because all alignments are now supported
(since ca. 20 years?).
So you can (temporarily) work around this by filling in blit_x,
preventing the use of the 7x14 font.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Geert Uytterhoeven]

Hi Marek,

On Wed, Mar 9, 2022 at 10:22 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> On 09.03.2022 09:22, Thomas Zimmermann wrote:
> > Am 08.03.22 um 23:52 schrieb Marek Szyprowski:
> >> On 23.02.2022 20:38, Thomas Zimmermann wrote:
> >>> Improve the performance of cfb_imageblit() by manually unrolling
> >>> the inner blitting loop and moving some invariants out. The compiler
> >>> failed to do this automatically. This change keeps cfb_imageblit()
> >>> in sync with sys_imagebit().
> >>>
> >>> A microbenchmark measures the average number of CPU cycles
> >>> for cfb_imageblit() after a stabilizing period of a few minutes
> >>> (i7-4790, FullHD, simpledrm, kernel with debugging).
> >>>
> >>> cfb_imageblit(), new: 15724 cycles
> >>> cfb_imageblit(): old: 30566 cycles
> >>>
> >>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
> >>>
> >>> v3:
> >>>     * fix commit description (Pekka)
> >>>
> >>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> >>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> >>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> >> This patch landed recently in linux next-20220308 as commit 0d03011894d2
> >> ("fbdev: Improve performance of cfb_imageblit()"). Sadly it causes a
> >> freeze after DRM and emulated fbdev initialization on various Samsung
> >> Exynos ARM 32bit based boards. This happens when kernel is compiled from
> >> exynos_defconfig. Surprisingly when kernel is compiled from
> >> multi_v7_defconfig all those boards boot fine, so this is a matter of
> >> one of the debugging options enabled in the exynos_defconfig. I will try
> >> to analyze this further and share the results. Reverting $subject on top
> >> of next-20220308 fixes the boot issue.
> >
> > Thanks for reporting. I don't have the hardware to reproduce it and
> > there's no obvious difference to the original version. It's supposed
> > to be the same algorithm with a different implementation. Unless you
> > can figure out the issue, we can also revert the patch easily.
>
> I've played a bit with .config options and found that the issue is
> caused by the compiled-in fonts used for the framebuffer. For some
> reasons (so far unknown to me), exynos_defconfig has the following odd
> setup:
>
> CONFIG_FONT_SUPPORT=y
> CONFIG_FONTS=y
> # CONFIG_FONT_8x8 is not set
> # CONFIG_FONT_8x16 is not set
> # CONFIG_FONT_6x11 is not set
> CONFIG_FONT_7x14=y
> # CONFIG_FONT_PEARL_8x8 is not set
> # CONFIG_FONT_ACORN_8x8 is not set
> # CONFIG_FONT_MINI_4x6 is not set
> # CONFIG_FONT_6x10 is not set
> # CONFIG_FONT_10x18 is not set
> # CONFIG_FONT_SUN8x16 is not set
> # CONFIG_FONT_SUN12x22 is not set
> # CONFIG_FONT_TER16x32 is not set
> # CONFIG_FONT_6x8 is not set
>
> Such setup causes a freeze during framebuffer initialization (or just
> after it got registered). I've reproduced this even on Raspberry Pi 3B
> with multi_v7_defconfig and changed fonts configuration (this also
> required to disable vivid driver, which forces 8x16 font), where I got
> the following panic:
>
> simple-framebuffer 3eace000.framebuffer: framebuffer at 0x3eace000,
> 0x12c000 bytes
> simple-framebuffer 3eace000.framebuffer: format=a8r8g8b8,
> mode=640x480x32, linelength=2560
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address f0aac000

So support for images with offsets or widths that are not a multiple
of 8 got broken in cfb_imageblit(). Oops...

BTW, the various drawing routines used to set a bitmask indicating
which alignments were supported (see blit_x), but most of them no
longer do, presumably because all alignments are now supported
(since ca. 20 years?).
So you can (temporarily) work around this by filling in blit_x,
preventing the use of the 7x14 font.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 4651 bytes --]

Hi

Am 09.03.22 um 11:39 schrieb Geert Uytterhoeven:
> Hi Marek,
> 
> On Wed, Mar 9, 2022 at 10:22 AM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 09.03.2022 09:22, Thomas Zimmermann wrote:
>>> Am 08.03.22 um 23:52 schrieb Marek Szyprowski:
>>>> On 23.02.2022 20:38, Thomas Zimmermann wrote:
>>>>> Improve the performance of cfb_imageblit() by manually unrolling
>>>>> the inner blitting loop and moving some invariants out. The compiler
>>>>> failed to do this automatically. This change keeps cfb_imageblit()
>>>>> in sync with sys_imagebit().
>>>>>
>>>>> A microbenchmark measures the average number of CPU cycles
>>>>> for cfb_imageblit() after a stabilizing period of a few minutes
>>>>> (i7-4790, FullHD, simpledrm, kernel with debugging).
>>>>>
>>>>> cfb_imageblit(), new: 15724 cycles
>>>>> cfb_imageblit(): old: 30566 cycles
>>>>>
>>>>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
>>>>>
>>>>> v3:
>>>>>      * fix commit description (Pekka)
>>>>>
>>>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>>>>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>>>> This patch landed recently in linux next-20220308 as commit 0d03011894d2
>>>> ("fbdev: Improve performance of cfb_imageblit()"). Sadly it causes a
>>>> freeze after DRM and emulated fbdev initialization on various Samsung
>>>> Exynos ARM 32bit based boards. This happens when kernel is compiled from
>>>> exynos_defconfig. Surprisingly when kernel is compiled from
>>>> multi_v7_defconfig all those boards boot fine, so this is a matter of
>>>> one of the debugging options enabled in the exynos_defconfig. I will try
>>>> to analyze this further and share the results. Reverting $subject on top
>>>> of next-20220308 fixes the boot issue.
>>>
>>> Thanks for reporting. I don't have the hardware to reproduce it and
>>> there's no obvious difference to the original version. It's supposed
>>> to be the same algorithm with a different implementation. Unless you
>>> can figure out the issue, we can also revert the patch easily.
>>
>> I've played a bit with .config options and found that the issue is
>> caused by the compiled-in fonts used for the framebuffer. For some
>> reasons (so far unknown to me), exynos_defconfig has the following odd
>> setup:
>>
>> CONFIG_FONT_SUPPORT=y
>> CONFIG_FONTS=y
>> # CONFIG_FONT_8x8 is not set
>> # CONFIG_FONT_8x16 is not set
>> # CONFIG_FONT_6x11 is not set
>> CONFIG_FONT_7x14=y
>> # CONFIG_FONT_PEARL_8x8 is not set
>> # CONFIG_FONT_ACORN_8x8 is not set
>> # CONFIG_FONT_MINI_4x6 is not set
>> # CONFIG_FONT_6x10 is not set
>> # CONFIG_FONT_10x18 is not set
>> # CONFIG_FONT_SUN8x16 is not set
>> # CONFIG_FONT_SUN12x22 is not set
>> # CONFIG_FONT_TER16x32 is not set
>> # CONFIG_FONT_6x8 is not set
>>
>> Such setup causes a freeze during framebuffer initialization (or just
>> after it got registered). I've reproduced this even on Raspberry Pi 3B
>> with multi_v7_defconfig and changed fonts configuration (this also
>> required to disable vivid driver, which forces 8x16 font), where I got
>> the following panic:
>>
>> simple-framebuffer 3eace000.framebuffer: framebuffer at 0x3eace000,
>> 0x12c000 bytes
>> simple-framebuffer 3eace000.framebuffer: format=a8r8g8b8,
>> mode=640x480x32, linelength=2560
>> 8<--- cut here ---
>> Unable to handle kernel paging request at virtual address f0aac000
> 
> So support for images with offsets or widths that are not a multiple
> of 8 got broken in cfb_imageblit(). Oops...
> 
> BTW, the various drawing routines used to set a bitmask indicating
> which alignments were supported (see blit_x), but most of them no
> longer do, presumably because all alignments are now supported
> (since ca. 20 years?).
> So you can (temporarily) work around this by filling in blit_x,
> preventing the use of the 7x14 font.

How do I activate the 7x14 font? It's compiled into the kernel already
(CONFIG_FONT_7x14=y).

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 4651 bytes --]

Hi

Am 09.03.22 um 11:39 schrieb Geert Uytterhoeven:
> Hi Marek,
> 
> On Wed, Mar 9, 2022 at 10:22 AM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 09.03.2022 09:22, Thomas Zimmermann wrote:
>>> Am 08.03.22 um 23:52 schrieb Marek Szyprowski:
>>>> On 23.02.2022 20:38, Thomas Zimmermann wrote:
>>>>> Improve the performance of cfb_imageblit() by manually unrolling
>>>>> the inner blitting loop and moving some invariants out. The compiler
>>>>> failed to do this automatically. This change keeps cfb_imageblit()
>>>>> in sync with sys_imagebit().
>>>>>
>>>>> A microbenchmark measures the average number of CPU cycles
>>>>> for cfb_imageblit() after a stabilizing period of a few minutes
>>>>> (i7-4790, FullHD, simpledrm, kernel with debugging).
>>>>>
>>>>> cfb_imageblit(), new: 15724 cycles
>>>>> cfb_imageblit(): old: 30566 cycles
>>>>>
>>>>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
>>>>>
>>>>> v3:
>>>>>      * fix commit description (Pekka)
>>>>>
>>>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>>>>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>>>> This patch landed recently in linux next-20220308 as commit 0d03011894d2
>>>> ("fbdev: Improve performance of cfb_imageblit()"). Sadly it causes a
>>>> freeze after DRM and emulated fbdev initialization on various Samsung
>>>> Exynos ARM 32bit based boards. This happens when kernel is compiled from
>>>> exynos_defconfig. Surprisingly when kernel is compiled from
>>>> multi_v7_defconfig all those boards boot fine, so this is a matter of
>>>> one of the debugging options enabled in the exynos_defconfig. I will try
>>>> to analyze this further and share the results. Reverting $subject on top
>>>> of next-20220308 fixes the boot issue.
>>>
>>> Thanks for reporting. I don't have the hardware to reproduce it and
>>> there's no obvious difference to the original version. It's supposed
>>> to be the same algorithm with a different implementation. Unless you
>>> can figure out the issue, we can also revert the patch easily.
>>
>> I've played a bit with .config options and found that the issue is
>> caused by the compiled-in fonts used for the framebuffer. For some
>> reasons (so far unknown to me), exynos_defconfig has the following odd
>> setup:
>>
>> CONFIG_FONT_SUPPORT=y
>> CONFIG_FONTS=y
>> # CONFIG_FONT_8x8 is not set
>> # CONFIG_FONT_8x16 is not set
>> # CONFIG_FONT_6x11 is not set
>> CONFIG_FONT_7x14=y
>> # CONFIG_FONT_PEARL_8x8 is not set
>> # CONFIG_FONT_ACORN_8x8 is not set
>> # CONFIG_FONT_MINI_4x6 is not set
>> # CONFIG_FONT_6x10 is not set
>> # CONFIG_FONT_10x18 is not set
>> # CONFIG_FONT_SUN8x16 is not set
>> # CONFIG_FONT_SUN12x22 is not set
>> # CONFIG_FONT_TER16x32 is not set
>> # CONFIG_FONT_6x8 is not set
>>
>> Such setup causes a freeze during framebuffer initialization (or just
>> after it got registered). I've reproduced this even on Raspberry Pi 3B
>> with multi_v7_defconfig and changed fonts configuration (this also
>> required to disable vivid driver, which forces 8x16 font), where I got
>> the following panic:
>>
>> simple-framebuffer 3eace000.framebuffer: framebuffer at 0x3eace000,
>> 0x12c000 bytes
>> simple-framebuffer 3eace000.framebuffer: format=a8r8g8b8,
>> mode=640x480x32, linelength=2560
>> 8<--- cut here ---
>> Unable to handle kernel paging request at virtual address f0aac000
> 
> So support for images with offsets or widths that are not a multiple
> of 8 got broken in cfb_imageblit(). Oops...
> 
> BTW, the various drawing routines used to set a bitmask indicating
> which alignments were supported (see blit_x), but most of them no
> longer do, presumably because all alignments are now supported
> (since ca. 20 years?).
> So you can (temporarily) work around this by filling in blit_x,
> preventing the use of the 7x14 font.

How do I activate the 7x14 font? It's compiled into the kernel already
(CONFIG_FONT_7x14=y).

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Geert Uytterhoeven]

Hi Thomas,

On Thu, Mar 10, 2022 at 8:22 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 09.03.22 um 11:39 schrieb Geert Uytterhoeven:
> > On Wed, Mar 9, 2022 at 10:22 AM Marek Szyprowski
> > <m.szyprowski@samsung.com> wrote:
> >> On 09.03.2022 09:22, Thomas Zimmermann wrote:
> >>> Am 08.03.22 um 23:52 schrieb Marek Szyprowski:
> >>>> On 23.02.2022 20:38, Thomas Zimmermann wrote:
> >>>>> Improve the performance of cfb_imageblit() by manually unrolling
> >>>>> the inner blitting loop and moving some invariants out. The compiler
> >>>>> failed to do this automatically. This change keeps cfb_imageblit()
> >>>>> in sync with sys_imagebit().
> >>>>>
> >>>>> A microbenchmark measures the average number of CPU cycles
> >>>>> for cfb_imageblit() after a stabilizing period of a few minutes
> >>>>> (i7-4790, FullHD, simpledrm, kernel with debugging).
> >>>>>
> >>>>> cfb_imageblit(), new: 15724 cycles
> >>>>> cfb_imageblit(): old: 30566 cycles
> >>>>>
> >>>>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
> >>>>>
> >>>>> v3:
> >>>>>      * fix commit description (Pekka)
> >>>>>
> >>>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> >>>>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> >>>>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> >>>> This patch landed recently in linux next-20220308 as commit 0d03011894d2
> >>>> ("fbdev: Improve performance of cfb_imageblit()"). Sadly it causes a
> >>>> freeze after DRM and emulated fbdev initialization on various Samsung
> >>>> Exynos ARM 32bit based boards. This happens when kernel is compiled from
> >>>> exynos_defconfig. Surprisingly when kernel is compiled from
> >>>> multi_v7_defconfig all those boards boot fine, so this is a matter of
> >>>> one of the debugging options enabled in the exynos_defconfig. I will try
> >>>> to analyze this further and share the results. Reverting $subject on top
> >>>> of next-20220308 fixes the boot issue.
> >>>
> >>> Thanks for reporting. I don't have the hardware to reproduce it and
> >>> there's no obvious difference to the original version. It's supposed
> >>> to be the same algorithm with a different implementation. Unless you
> >>> can figure out the issue, we can also revert the patch easily.
> >>
> >> I've played a bit with .config options and found that the issue is
> >> caused by the compiled-in fonts used for the framebuffer. For some
> >> reasons (so far unknown to me), exynos_defconfig has the following odd
> >> setup:
> >>
> >> CONFIG_FONT_SUPPORT=y
> >> CONFIG_FONTS=y
> >> # CONFIG_FONT_8x8 is not set
> >> # CONFIG_FONT_8x16 is not set
> >> # CONFIG_FONT_6x11 is not set
> >> CONFIG_FONT_7x14=y
> >> # CONFIG_FONT_PEARL_8x8 is not set
> >> # CONFIG_FONT_ACORN_8x8 is not set
> >> # CONFIG_FONT_MINI_4x6 is not set
> >> # CONFIG_FONT_6x10 is not set
> >> # CONFIG_FONT_10x18 is not set
> >> # CONFIG_FONT_SUN8x16 is not set
> >> # CONFIG_FONT_SUN12x22 is not set
> >> # CONFIG_FONT_TER16x32 is not set
> >> # CONFIG_FONT_6x8 is not set
> >>
> >> Such setup causes a freeze during framebuffer initialization (or just
> >> after it got registered). I've reproduced this even on Raspberry Pi 3B
> >> with multi_v7_defconfig and changed fonts configuration (this also
> >> required to disable vivid driver, which forces 8x16 font), where I got
> >> the following panic:
> >>
> >> simple-framebuffer 3eace000.framebuffer: framebuffer at 0x3eace000,
> >> 0x12c000 bytes
> >> simple-framebuffer 3eace000.framebuffer: format=a8r8g8b8,
> >> mode=640x480x32, linelength=2560
> >> 8<--- cut here ---
> >> Unable to handle kernel paging request at virtual address f0aac000
> >
> > So support for images with offsets or widths that are not a multiple
> > of 8 got broken in cfb_imageblit(). Oops...
> >
> > BTW, the various drawing routines used to set a bitmask indicating
> > which alignments were supported (see blit_x), but most of them no
> > longer do, presumably because all alignments are now supported
> > (since ca. 20 years?).
> > So you can (temporarily) work around this by filling in blit_x,
> > preventing the use of the 7x14 font.
>
> How do I activate the 7x14 font? It's compiled into the kernel already
> (CONFIG_FONT_7x14=y).

Documentation/fb/fbcon.rst:1. fbcon=font:<name>

Or just disable all other fonts.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Geert Uytterhoeven]

Hi Thomas,

On Thu, Mar 10, 2022 at 8:22 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 09.03.22 um 11:39 schrieb Geert Uytterhoeven:
> > On Wed, Mar 9, 2022 at 10:22 AM Marek Szyprowski
> > <m.szyprowski@samsung.com> wrote:
> >> On 09.03.2022 09:22, Thomas Zimmermann wrote:
> >>> Am 08.03.22 um 23:52 schrieb Marek Szyprowski:
> >>>> On 23.02.2022 20:38, Thomas Zimmermann wrote:
> >>>>> Improve the performance of cfb_imageblit() by manually unrolling
> >>>>> the inner blitting loop and moving some invariants out. The compiler
> >>>>> failed to do this automatically. This change keeps cfb_imageblit()
> >>>>> in sync with sys_imagebit().
> >>>>>
> >>>>> A microbenchmark measures the average number of CPU cycles
> >>>>> for cfb_imageblit() after a stabilizing period of a few minutes
> >>>>> (i7-4790, FullHD, simpledrm, kernel with debugging).
> >>>>>
> >>>>> cfb_imageblit(), new: 15724 cycles
> >>>>> cfb_imageblit(): old: 30566 cycles
> >>>>>
> >>>>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
> >>>>>
> >>>>> v3:
> >>>>>      * fix commit description (Pekka)
> >>>>>
> >>>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> >>>>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> >>>>> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> >>>> This patch landed recently in linux next-20220308 as commit 0d03011894d2
> >>>> ("fbdev: Improve performance of cfb_imageblit()"). Sadly it causes a
> >>>> freeze after DRM and emulated fbdev initialization on various Samsung
> >>>> Exynos ARM 32bit based boards. This happens when kernel is compiled from
> >>>> exynos_defconfig. Surprisingly when kernel is compiled from
> >>>> multi_v7_defconfig all those boards boot fine, so this is a matter of
> >>>> one of the debugging options enabled in the exynos_defconfig. I will try
> >>>> to analyze this further and share the results. Reverting $subject on top
> >>>> of next-20220308 fixes the boot issue.
> >>>
> >>> Thanks for reporting. I don't have the hardware to reproduce it and
> >>> there's no obvious difference to the original version. It's supposed
> >>> to be the same algorithm with a different implementation. Unless you
> >>> can figure out the issue, we can also revert the patch easily.
> >>
> >> I've played a bit with .config options and found that the issue is
> >> caused by the compiled-in fonts used for the framebuffer. For some
> >> reasons (so far unknown to me), exynos_defconfig has the following odd
> >> setup:
> >>
> >> CONFIG_FONT_SUPPORT=y
> >> CONFIG_FONTS=y
> >> # CONFIG_FONT_8x8 is not set
> >> # CONFIG_FONT_8x16 is not set
> >> # CONFIG_FONT_6x11 is not set
> >> CONFIG_FONT_7x14=y
> >> # CONFIG_FONT_PEARL_8x8 is not set
> >> # CONFIG_FONT_ACORN_8x8 is not set
> >> # CONFIG_FONT_MINI_4x6 is not set
> >> # CONFIG_FONT_6x10 is not set
> >> # CONFIG_FONT_10x18 is not set
> >> # CONFIG_FONT_SUN8x16 is not set
> >> # CONFIG_FONT_SUN12x22 is not set
> >> # CONFIG_FONT_TER16x32 is not set
> >> # CONFIG_FONT_6x8 is not set
> >>
> >> Such setup causes a freeze during framebuffer initialization (or just
> >> after it got registered). I've reproduced this even on Raspberry Pi 3B
> >> with multi_v7_defconfig and changed fonts configuration (this also
> >> required to disable vivid driver, which forces 8x16 font), where I got
> >> the following panic:
> >>
> >> simple-framebuffer 3eace000.framebuffer: framebuffer at 0x3eace000,
> >> 0x12c000 bytes
> >> simple-framebuffer 3eace000.framebuffer: format=a8r8g8b8,
> >> mode=640x480x32, linelength=2560
> >> 8<--- cut here ---
> >> Unable to handle kernel paging request at virtual address f0aac000
> >
> > So support for images with offsets or widths that are not a multiple
> > of 8 got broken in cfb_imageblit(). Oops...
> >
> > BTW, the various drawing routines used to set a bitmask indicating
> > which alignments were supported (see blit_x), but most of them no
> > longer do, presumably because all alignments are now supported
> > (since ca. 20 years?).
> > So you can (temporarily) work around this by filling in blit_x,
> > preventing the use of the 7x14 font.
>
> How do I activate the 7x14 font? It's compiled into the kernel already
> (CONFIG_FONT_7x14=y).

Documentation/fb/fbcon.rst:1. fbcon=font:<name>

Or just disable all other fonts.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 941 bytes --]

Hi Geert

Am 10.03.22 um 20:23 schrieb Geert Uytterhoeven:
[...]
>>
>> How do I activate the 7x14 font? It's compiled into the kernel already
>> (CONFIG_FONT_7x14=y).
> 
> Documentation/fb/fbcon.rst:1. fbcon=font:<name>
> 
> Or just disable all other fonts.

Thanks. I've been able to reproduce the problem and will send a patch soon.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [v3,4/5] fbdev: Improve performance of cfb_imageblit()

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 941 bytes --]

Hi Geert

Am 10.03.22 um 20:23 schrieb Geert Uytterhoeven:
[...]
>>
>> How do I activate the 7x14 font? It's compiled into the kernel already
>> (CONFIG_FONT_7x14=y).
> 
> Documentation/fb/fbcon.rst:1. fbcon=font:<name>
> 
> Or just disable all other fonts.

Thanks. I've been able to reproduce the problem and will send a patch soon.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Guenter Roeck]

Hi,

On Wed, Feb 23, 2022 at 08:38:03PM +0100, Thomas Zimmermann wrote:
> Improve the performance of cfb_imageblit() by manually unrolling
> the inner blitting loop and moving some invariants out. The compiler
> failed to do this automatically. This change keeps cfb_imageblit()
> in sync with sys_imagebit().
> 
> A microbenchmark measures the average number of CPU cycles
> for cfb_imageblit() after a stabilizing period of a few minutes
> (i7-4790, FullHD, simpledrm, kernel with debugging).
> 
> cfb_imageblit(), new: 15724 cycles
> cfb_imageblit(): old: 30566 cycles
> 
> In the optimized case, cfb_imageblit() is now ~2x faster than before.
> 
> v3:
> 	* fix commit description (Pekka)
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

This patch causes crashes with arm mainstone, z2, and collie emulations.
Reverting it fixes the problem.

collie crash log and bisect log attached.

Guenter

---
8<--- cut here ---
Unable to handle kernel paging request at virtual address e090d000
[e090d000] *pgd=c0c0b811c0c0b811, *pte=c0c0b000, *ppte=00000000
Internal error: Oops: 807 [#1] ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 5.17.0-next-20220324 #1
Hardware name: Sharp-Collie
PC is at cfb_imageblit+0x58c/0x6e0
LR is at 0x5
pc : [<c040eab0>]    lr : [<00000005>]    psr: a0000153
sp : e0809958  ip : e090d000  fp : e08099f4
r10: e08099c8  r9 : c0c70600  r8 : ffff6802
r7 : c0c6e000  r6 : 00000000  r5 : e08e7000  r4 : 00000280
r3 : 00000020  r2 : 00000003  r1 : 00000002  r0 : 00000002
Flags: NzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
Control: 0000717f  Table: c0004000  DAC: 00000053
Register r0 information: non-paged memory
Register r1 information: non-paged memory
Register r2 information: non-paged memory
Register r3 information: non-paged memory
Register r4 information: non-paged memory
Register r5 information: 0-page vmalloc region starting at 0xe08e6000 allocated at dma_common_contiguous_remap+0x94/0xb0
Register r6 information: NULL pointer
Register r7 information: non-slab/vmalloc memory
Register r8 information: non-paged memory
Register r9 information: non-slab/vmalloc memory
Register r10 information: 2-page vmalloc region starting at 0xe0808000 allocated at kernel_clone+0x78/0x4e4
Register r11 information: 2-page vmalloc region starting at 0xe0808000 allocated at kernel_clone+0x78/0x4e4
Register r12 information: 0-page vmalloc region starting at 0xe08e6000 allocated at dma_common_contiguous_remap+0x94/0xb0
Process swapper (pid: 1, stack limit = 0x(ptrval))
Stack: (0xe0809958 to 0xe080a000)
9940:                                                       80000153 0000005e
9960: dfb1b424 00000020 00000000 00000000 00000001 00000002 00000003 00000004
9980: dfb1b420 00000000 00000000 00000000 00000000 c067f338 e08099ab 00000026
99a0: 80000153 00000820 007fe178 c07db82c e08099d4 0000003e 00000820 c0e32b00
99c0: 00000006 c07db82c 00000001 c0da1e40 e0809a54 c0e32b00 00000006 00000001
99e0: 00000001 c0c6e000 e0809a34 e08099f8 c040a3f8 c040e530 00000006 00000001
9a00: c0e61920 c0da1e78 00000000 c0e61920 00000000 e0809a54 c06ad89c c0e32b00
9a20: c0da1e00 00000020 e0809acc e0809a38 c040a040 c040a26c e0809a7c 00000140
9a40: 00000002 00000002 00000001 00000007 00000000 00000039 00000001 c0da1e00
9a60: 00000000 00000000 00000000 00000004 00000006 00000007 00000000 00000001
9a80: c06ad89c 00000000 00000000 00000000 00000000 ffffffff ffffffff c07db82c
9aa0: e0809acc c0c0c3c0 c0e32b00 00000007 00000002 00000720 c0409cf0 00000028
9ac0: e0809afc e0809ad0 c040665c c0409cfc 00000000 00000000 c0c0c3c0 c0807584
9ae0: 00000000 00000000 ffffff60 c0c70000 e0809b1c e0809b00 c0439a50 c040656c
9b00: c0c0c3c0 00000000 00000000 00000000 e0809b54 e0809b20 c043a798 c0439a24
9b20: c04095c8 c0c6ff60 00000000 c07db82c e0809b54 c0c0c3c0 c0c6ff60 00000000
9b40: 00000000 ffffff60 e0809ba4 e0809b58 c0407254 c043a5ac e0809b7c e0809b68
9b60: c04145d8 00000000 00000000 00000000 00000720 00000000 00000050 c0c0c3c0
9b80: c0e32b00 c0e61920 00000050 00000028 c0a00df8 00000028 e0809bec e0809ba8
9ba0: c0407748 c0406f04 00000050 00000028 00000050 00000001 c0a02f70 00000000
9bc0: 00000000 c0c0c3c0 c0c0c624 00000000 c0a02f84 0000003e 00000000 c0a03080
9be0: e0809c0c e0809bf0 c0438b10 c040734c c0c0c3c0 c06affbc 00000001 c0a02f84
9c00: e0809c54 e0809c10 c043be28 c0438a80 0000003e 00000001 00000000 c0779d88
9c20: 00000000 00000001 c08075a8 c06affbc 00000000 00000001 00000000 0000003e
9c40: 00000001 c0a02f8c e0809c9c e0809c58 c043c6ec c043bc98 c08075a8 c077c29c
9c60: 00000001 00000000 c0e32b44 c0a03a58 c067f354 c0805a24 c0a00cc8 c0805a24
9c80: 00000000 c07dbabc c0e32da4 fffff000 e0809cb4 e0809ca0 c0405d5c c043c5d4
9ca0: c0a00dac 00000000 e0809cd4 e0809cb8 c0408f48 c0405cfc c0e32b00 00000000
9cc0: c0a00ca8 c0e32b10 e0809d44 e0809cd8 c03ff9e4 c0408e70 c0779a14 00000000
9ce0: c000ea7c 00000000 00000041 00000140 000000f0 00029e01 0000000b 0000001e
9d00: 00000002 00000000 00000005 00000001 00000003 00000000 00000020 c07db82c
9d20: c0e32b00 00000000 c07dfe08 00000004 0000000d 00000000 e0809d84 e0809d48
9d40: c040f550 c03ff7e8 00000004 c077a1b8 c0e32b00 c0180a04 c07dfe18 00000000
9d60: c07dfe18 c0805abc 00000000 00000000 c07cb87c c07cb85c e0809da4 e0809d88
9d80: c045c2c8 c040f228 00000000 c07dfe18 c0805abc 00000000 e0809dc4 e0809da8
9da0: c045a304 c045c288 c07dfe18 c0805abc c07dfe18 00000000 e0809ddc e0809dc8
9dc0: c045a548 c045a250 c0a04c6c 60000153 e0809e04 e0809de0 c045a5f4 c045a4d0
9de0: e0809e04 e0809df0 c07dfe18 c0805abc c045a7d0 c080af60 e0809e24 e0809e08
9e00: c045a860 c045a5b4 00000000 c0805abc c045a7d0 c080af60 e0809e54 e0809e28
9e20: c0458694 c045a7dc c0c30e20 c0c30dec c0c9f3b4 c07db82c c06559b8 c0805abc
9e40: c0e5d340 00000000 e0809e64 e0809e58 c045adf0 c0458620 e0809e8c e0809e68
9e60: c0458fb8 c045addc c0749e14 e0809e78 c0805abc c0c19000 c07bc340 c07a4bc8
9e80: e0809ea4 e0809e90 c045b684 c0458e84 c0818000 c0c19000 e0809eb4 e0809ea8
9ea0: c045d10c c045b614 e0809ec4 e0809eb8 c07bc368 c045d0f8 e0809f4c e0809ec8
9ec0: c07a821c c07bc34c e0809eec e0809ed8 c00374f4 c065f390 c0c427da c07a5600
9ee0: e0809f4c e0809ef0 c00376f4 c07a7448 e0809f03 00000006 00000006 00000000
9f00: 00000000 c07a743c c0793b5c c07a4bc8 00000dc0 c0c427cc c0c427d4 c07db82c
9f20: 00000000 c07d2060 c0c427a0 00000007 c07a4bc8 c0818000 c07cb87c c07cb85c
9f40: e0809f94 e0809f50 c07a85a0 c07a81b0 00000006 00000006 00000000 c07a743c
9f60: c0c19000 0000008c e0809f8c 00000000 c0675804 00000000 00000000 00000000
9f80: 00000000 00000000 e0809fac e0809f98 c067581c c07a842c 00000000 c0675804
9fa0: 00000000 e0809fb0 c0008328 c0675810 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
Backtrace:
 cfb_imageblit from soft_cursor+0x198/0x1fc
 r10:c0c6e000 r9:00000001 r8:00000001 r7:00000006 r6:c0e32b00 r5:e0809a54
 r4:c0da1e40
 soft_cursor from bit_cursor+0x350/0x4fc
 r10:00000020 r9:c0da1e00 r8:c0e32b00 r7:c06ad89c r6:e0809a54 r5:00000000
 r4:c0e61920
 bit_cursor from fbcon_cursor+0xfc/0x110
 r10:00000028 r9:c0409cf0 r8:00000720 r7:00000002 r6:00000007 r5:c0e32b00
 r4:c0c0c3c0
 fbcon_cursor from hide_cursor+0x38/0xac
 r9:c0c70000 r8:ffffff60 r7:00000000 r6:00000000 r5:c0807584 r4:c0c0c3c0
 hide_cursor from redraw_screen+0x1f8/0x258
 r7:00000000 r6:00000000 r5:00000000 r4:c0c0c3c0
 redraw_screen from fbcon_prepare_logo+0x35c/0x448
 r8:ffffff60 r7:00000000 r6:00000000 r5:c0c6ff60 r4:c0c0c3c0
 fbcon_prepare_logo from fbcon_init+0x408/0x4f8
 r10:00000028 r9:c0a00df8 r8:00000028 r7:00000050 r6:c0e61920 r5:c0e32b00
 r4:c0c0c3c0
 fbcon_init from visual_init+0x9c/0xe0
 r10:c0a03080 r9:00000000 r8:0000003e r7:c0a02f84 r6:00000000 r5:c0c0c624
 r4:c0c0c3c0
 visual_init from do_bind_con_driver+0x19c/0x370
 r7:c0a02f84 r6:00000001 r5:c06affbc r4:c0c0c3c0
 do_bind_con_driver from do_take_over_console+0x124/0x1b8
 r10:c0a02f8c r9:00000001 r8:0000003e r7:00000000 r6:00000001 r5:00000000
 r4:c06affbc
 do_take_over_console from do_fbcon_takeover+0x6c/0xcc
 r10:fffff000 r9:c0e32da4 r8:c07dbabc r7:00000000 r6:c0805a24 r5:c0a00cc8
 r4:c0805a24
 do_fbcon_takeover from fbcon_fb_registered+0xe4/0x128
 r5:00000000 r4:c0a00dac
 fbcon_fb_registered from register_framebuffer+0x208/0x318
 r7:c0e32b10 r6:c0a00ca8 r5:00000000 r4:c0e32b00
 register_framebuffer from sa1100fb_probe+0x334/0x420
 r9:00000000 r8:0000000d r7:00000004 r6:c07dfe08 r5:00000000 r4:c0e32b00
 sa1100fb_probe from platform_probe+0x4c/0xac
 r10:c07cb85c r9:c07cb87c r8:00000000 r7:00000000 r6:c0805abc r5:c07dfe18
 r4:00000000
 platform_probe from really_probe+0xc0/0x280
 r7:00000000 r6:c0805abc r5:c07dfe18 r4:00000000
 really_probe from __driver_probe_device+0x84/0xe4
 r7:00000000 r6:c07dfe18 r5:c0805abc r4:c07dfe18
 __driver_probe_device from driver_probe_device+0x4c/0x10c
 r5:60000153 r4:c0a04c6c
 driver_probe_device from __driver_attach+0x90/0x104
 r7:c080af60 r6:c045a7d0 r5:c0805abc r4:c07dfe18
 __driver_attach from bus_for_each_dev+0x80/0xcc
 r7:c080af60 r6:c045a7d0 r5:c0805abc r4:00000000
 bus_for_each_dev from driver_attach+0x20/0x28
 r6:00000000 r5:c0e5d340 r4:c0805abc
 driver_attach from bus_add_driver+0x140/0x1c8
 bus_add_driver from driver_register+0x7c/0x110
 r7:c07a4bc8 r6:c07bc340 r5:c0c19000 r4:c0805abc
 driver_register from __platform_driver_register+0x20/0x28
 r5:c0c19000 r4:c0818000
 __platform_driver_register from sa1100fb_init+0x28/0x3c
 sa1100fb_init from do_one_initcall+0x78/0x220
 do_one_initcall from kernel_init_freeable+0x180/0x1fc
 r10:c07cb85c r9:c07cb87c r8:c0818000 r7:c07a4bc8 r6:00000007 r5:c0c427a0
 r4:c07d2060
 kernel_init_freeable from kernel_init+0x18/0x10c
 r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0675804
 r4:00000000
 kernel_init from ret_from_fork+0x14/0x2c
Exception stack(0xe0809fb0 to 0xe0809ff8)
9fa0:                                     00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
 r5:c0675804 r4:00000000
Code: e24ba02c e0026323 e08a6106 e5166044 (e58c6000)
---[ end trace 00000000c08187d8 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Reboot failed -- System halted

---
# bad: [dd315b5800612e6913343524aa9b993f9a8bb0cf] Add linux-next specific files for 20220324
# good: [f443e374ae131c168a065ea1748feac6b2e76613] Linux 5.17
git bisect start 'HEAD' 'v5.17'
# good: [6788381e2f3c20c25cf7ab91df9cf0d6bec153f9] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
git bisect good 6788381e2f3c20c25cf7ab91df9cf0d6bec153f9
# bad: [59c7e0caa3e7bc21dd1b6c681c87d2b307f399ee] Merge branch 'drm-next' of git://git.freedesktop.org/git/drm/drm.git
git bisect bad 59c7e0caa3e7bc21dd1b6c681c87d2b307f399ee
# good: [4d17d43de9d186150b3289ce99d7a79fcff202f9] net: usb: asix: suspend embedded PHY if external is used
git bisect good 4d17d43de9d186150b3289ce99d7a79fcff202f9
# good: [6c64ae228f0826859c56711ce133aff037d6205f] Backmerge tag 'v5.17-rc6' into drm-next
git bisect good 6c64ae228f0826859c56711ce133aff037d6205f
# good: [01fd8d2522c49a333b0ee46ba19a6fedfc1c9a60] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
git bisect good 01fd8d2522c49a333b0ee46ba19a6fedfc1c9a60
# bad: [6de7e4f02640fba2ffa6ac04e2be13785d614175] Merge tag 'drm-msm-next-2022-03-01' of https://gitlab.freedesktop.org/drm/msm into drm-next
git bisect bad 6de7e4f02640fba2ffa6ac04e2be13785d614175
# bad: [c9e9ce0b6f85ac330adee912745048a0af5f315d] Merge tag 'drm-misc-next-2022-03-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
git bisect bad c9e9ce0b6f85ac330adee912745048a0af5f315d
# good: [e2573d5f2a5cebe789bbf415e484b589d8eebad7] drm/amd/display: limit unbounded requesting to 5k
git bisect good e2573d5f2a5cebe789bbf415e484b589d8eebad7
# good: [3c54c95bd917d43d12fe1b192df9aa4c5973449b] fbdev: Remove trailing whitespaces from cfbimgblt.c
git bisect good 3c54c95bd917d43d12fe1b192df9aa4c5973449b
# good: [ed6e76676b2657b71a0b9e5e847d96e4de0b394b] drm: rcar-du: lvds: Add r8a77961 support
git bisect good ed6e76676b2657b71a0b9e5e847d96e4de0b394b
# good: [66a8af1f6e3c10190dff14a5668661c092a2a85f] Merge tag 'drm/tegra/for-5.18-rc1' of https://gitlab.freedesktop.org/drm/tegra into drm-next
git bisect good 66a8af1f6e3c10190dff14a5668661c092a2a85f
# bad: [701920ca9822eb63b420b3bcb627f2c1ec759903] drm/ssd130x: remove redundant initialization of pointer mode
git bisect bad 701920ca9822eb63b420b3bcb627f2c1ec759903
# bad: [9ae2ac4d31a85ce59cc560d514a31b95f4ace154] drm: Add TODO item for optimizing format helpers
git bisect bad 9ae2ac4d31a85ce59cc560d514a31b95f4ace154
# bad: [0d03011894d23241db1a1cad5c12aede60897d5e] fbdev: Improve performance of cfb_imageblit()
git bisect bad 0d03011894d23241db1a1cad5c12aede60897d5e
# first bad commit: [0d03011894d23241db1a1cad5c12aede60897d5e] fbdev: Improve performance of cfb_imageblit()

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Guenter Roeck]

Hi,

On Wed, Feb 23, 2022 at 08:38:03PM +0100, Thomas Zimmermann wrote:
> Improve the performance of cfb_imageblit() by manually unrolling
> the inner blitting loop and moving some invariants out. The compiler
> failed to do this automatically. This change keeps cfb_imageblit()
> in sync with sys_imagebit().
> 
> A microbenchmark measures the average number of CPU cycles
> for cfb_imageblit() after a stabilizing period of a few minutes
> (i7-4790, FullHD, simpledrm, kernel with debugging).
> 
> cfb_imageblit(), new: 15724 cycles
> cfb_imageblit(): old: 30566 cycles
> 
> In the optimized case, cfb_imageblit() is now ~2x faster than before.
> 
> v3:
> 	* fix commit description (Pekka)
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

This patch causes crashes with arm mainstone, z2, and collie emulations.
Reverting it fixes the problem.

collie crash log and bisect log attached.

Guenter

---
8<--- cut here ---
Unable to handle kernel paging request at virtual address e090d000
[e090d000] *pgd=c0c0b811c0c0b811, *pte=c0c0b000, *ppte=00000000
Internal error: Oops: 807 [#1] ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 5.17.0-next-20220324 #1
Hardware name: Sharp-Collie
PC is at cfb_imageblit+0x58c/0x6e0
LR is at 0x5
pc : [<c040eab0>]    lr : [<00000005>]    psr: a0000153
sp : e0809958  ip : e090d000  fp : e08099f4
r10: e08099c8  r9 : c0c70600  r8 : ffff6802
r7 : c0c6e000  r6 : 00000000  r5 : e08e7000  r4 : 00000280
r3 : 00000020  r2 : 00000003  r1 : 00000002  r0 : 00000002
Flags: NzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
Control: 0000717f  Table: c0004000  DAC: 00000053
Register r0 information: non-paged memory
Register r1 information: non-paged memory
Register r2 information: non-paged memory
Register r3 information: non-paged memory
Register r4 information: non-paged memory
Register r5 information: 0-page vmalloc region starting at 0xe08e6000 allocated at dma_common_contiguous_remap+0x94/0xb0
Register r6 information: NULL pointer
Register r7 information: non-slab/vmalloc memory
Register r8 information: non-paged memory
Register r9 information: non-slab/vmalloc memory
Register r10 information: 2-page vmalloc region starting at 0xe0808000 allocated at kernel_clone+0x78/0x4e4
Register r11 information: 2-page vmalloc region starting at 0xe0808000 allocated at kernel_clone+0x78/0x4e4
Register r12 information: 0-page vmalloc region starting at 0xe08e6000 allocated at dma_common_contiguous_remap+0x94/0xb0
Process swapper (pid: 1, stack limit = 0x(ptrval))
Stack: (0xe0809958 to 0xe080a000)
9940:                                                       80000153 0000005e
9960: dfb1b424 00000020 00000000 00000000 00000001 00000002 00000003 00000004
9980: dfb1b420 00000000 00000000 00000000 00000000 c067f338 e08099ab 00000026
99a0: 80000153 00000820 007fe178 c07db82c e08099d4 0000003e 00000820 c0e32b00
99c0: 00000006 c07db82c 00000001 c0da1e40 e0809a54 c0e32b00 00000006 00000001
99e0: 00000001 c0c6e000 e0809a34 e08099f8 c040a3f8 c040e530 00000006 00000001
9a00: c0e61920 c0da1e78 00000000 c0e61920 00000000 e0809a54 c06ad89c c0e32b00
9a20: c0da1e00 00000020 e0809acc e0809a38 c040a040 c040a26c e0809a7c 00000140
9a40: 00000002 00000002 00000001 00000007 00000000 00000039 00000001 c0da1e00
9a60: 00000000 00000000 00000000 00000004 00000006 00000007 00000000 00000001
9a80: c06ad89c 00000000 00000000 00000000 00000000 ffffffff ffffffff c07db82c
9aa0: e0809acc c0c0c3c0 c0e32b00 00000007 00000002 00000720 c0409cf0 00000028
9ac0: e0809afc e0809ad0 c040665c c0409cfc 00000000 00000000 c0c0c3c0 c0807584
9ae0: 00000000 00000000 ffffff60 c0c70000 e0809b1c e0809b00 c0439a50 c040656c
9b00: c0c0c3c0 00000000 00000000 00000000 e0809b54 e0809b20 c043a798 c0439a24
9b20: c04095c8 c0c6ff60 00000000 c07db82c e0809b54 c0c0c3c0 c0c6ff60 00000000
9b40: 00000000 ffffff60 e0809ba4 e0809b58 c0407254 c043a5ac e0809b7c e0809b68
9b60: c04145d8 00000000 00000000 00000000 00000720 00000000 00000050 c0c0c3c0
9b80: c0e32b00 c0e61920 00000050 00000028 c0a00df8 00000028 e0809bec e0809ba8
9ba0: c0407748 c0406f04 00000050 00000028 00000050 00000001 c0a02f70 00000000
9bc0: 00000000 c0c0c3c0 c0c0c624 00000000 c0a02f84 0000003e 00000000 c0a03080
9be0: e0809c0c e0809bf0 c0438b10 c040734c c0c0c3c0 c06affbc 00000001 c0a02f84
9c00: e0809c54 e0809c10 c043be28 c0438a80 0000003e 00000001 00000000 c0779d88
9c20: 00000000 00000001 c08075a8 c06affbc 00000000 00000001 00000000 0000003e
9c40: 00000001 c0a02f8c e0809c9c e0809c58 c043c6ec c043bc98 c08075a8 c077c29c
9c60: 00000001 00000000 c0e32b44 c0a03a58 c067f354 c0805a24 c0a00cc8 c0805a24
9c80: 00000000 c07dbabc c0e32da4 fffff000 e0809cb4 e0809ca0 c0405d5c c043c5d4
9ca0: c0a00dac 00000000 e0809cd4 e0809cb8 c0408f48 c0405cfc c0e32b00 00000000
9cc0: c0a00ca8 c0e32b10 e0809d44 e0809cd8 c03ff9e4 c0408e70 c0779a14 00000000
9ce0: c000ea7c 00000000 00000041 00000140 000000f0 00029e01 0000000b 0000001e
9d00: 00000002 00000000 00000005 00000001 00000003 00000000 00000020 c07db82c
9d20: c0e32b00 00000000 c07dfe08 00000004 0000000d 00000000 e0809d84 e0809d48
9d40: c040f550 c03ff7e8 00000004 c077a1b8 c0e32b00 c0180a04 c07dfe18 00000000
9d60: c07dfe18 c0805abc 00000000 00000000 c07cb87c c07cb85c e0809da4 e0809d88
9d80: c045c2c8 c040f228 00000000 c07dfe18 c0805abc 00000000 e0809dc4 e0809da8
9da0: c045a304 c045c288 c07dfe18 c0805abc c07dfe18 00000000 e0809ddc e0809dc8
9dc0: c045a548 c045a250 c0a04c6c 60000153 e0809e04 e0809de0 c045a5f4 c045a4d0
9de0: e0809e04 e0809df0 c07dfe18 c0805abc c045a7d0 c080af60 e0809e24 e0809e08
9e00: c045a860 c045a5b4 00000000 c0805abc c045a7d0 c080af60 e0809e54 e0809e28
9e20: c0458694 c045a7dc c0c30e20 c0c30dec c0c9f3b4 c07db82c c06559b8 c0805abc
9e40: c0e5d340 00000000 e0809e64 e0809e58 c045adf0 c0458620 e0809e8c e0809e68
9e60: c0458fb8 c045addc c0749e14 e0809e78 c0805abc c0c19000 c07bc340 c07a4bc8
9e80: e0809ea4 e0809e90 c045b684 c0458e84 c0818000 c0c19000 e0809eb4 e0809ea8
9ea0: c045d10c c045b614 e0809ec4 e0809eb8 c07bc368 c045d0f8 e0809f4c e0809ec8
9ec0: c07a821c c07bc34c e0809eec e0809ed8 c00374f4 c065f390 c0c427da c07a5600
9ee0: e0809f4c e0809ef0 c00376f4 c07a7448 e0809f03 00000006 00000006 00000000
9f00: 00000000 c07a743c c0793b5c c07a4bc8 00000dc0 c0c427cc c0c427d4 c07db82c
9f20: 00000000 c07d2060 c0c427a0 00000007 c07a4bc8 c0818000 c07cb87c c07cb85c
9f40: e0809f94 e0809f50 c07a85a0 c07a81b0 00000006 00000006 00000000 c07a743c
9f60: c0c19000 0000008c e0809f8c 00000000 c0675804 00000000 00000000 00000000
9f80: 00000000 00000000 e0809fac e0809f98 c067581c c07a842c 00000000 c0675804
9fa0: 00000000 e0809fb0 c0008328 c0675810 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
Backtrace:
 cfb_imageblit from soft_cursor+0x198/0x1fc
 r10:c0c6e000 r9:00000001 r8:00000001 r7:00000006 r6:c0e32b00 r5:e0809a54
 r4:c0da1e40
 soft_cursor from bit_cursor+0x350/0x4fc
 r10:00000020 r9:c0da1e00 r8:c0e32b00 r7:c06ad89c r6:e0809a54 r5:00000000
 r4:c0e61920
 bit_cursor from fbcon_cursor+0xfc/0x110
 r10:00000028 r9:c0409cf0 r8:00000720 r7:00000002 r6:00000007 r5:c0e32b00
 r4:c0c0c3c0
 fbcon_cursor from hide_cursor+0x38/0xac
 r9:c0c70000 r8:ffffff60 r7:00000000 r6:00000000 r5:c0807584 r4:c0c0c3c0
 hide_cursor from redraw_screen+0x1f8/0x258
 r7:00000000 r6:00000000 r5:00000000 r4:c0c0c3c0
 redraw_screen from fbcon_prepare_logo+0x35c/0x448
 r8:ffffff60 r7:00000000 r6:00000000 r5:c0c6ff60 r4:c0c0c3c0
 fbcon_prepare_logo from fbcon_init+0x408/0x4f8
 r10:00000028 r9:c0a00df8 r8:00000028 r7:00000050 r6:c0e61920 r5:c0e32b00
 r4:c0c0c3c0
 fbcon_init from visual_init+0x9c/0xe0
 r10:c0a03080 r9:00000000 r8:0000003e r7:c0a02f84 r6:00000000 r5:c0c0c624
 r4:c0c0c3c0
 visual_init from do_bind_con_driver+0x19c/0x370
 r7:c0a02f84 r6:00000001 r5:c06affbc r4:c0c0c3c0
 do_bind_con_driver from do_take_over_console+0x124/0x1b8
 r10:c0a02f8c r9:00000001 r8:0000003e r7:00000000 r6:00000001 r5:00000000
 r4:c06affbc
 do_take_over_console from do_fbcon_takeover+0x6c/0xcc
 r10:fffff000 r9:c0e32da4 r8:c07dbabc r7:00000000 r6:c0805a24 r5:c0a00cc8
 r4:c0805a24
 do_fbcon_takeover from fbcon_fb_registered+0xe4/0x128
 r5:00000000 r4:c0a00dac
 fbcon_fb_registered from register_framebuffer+0x208/0x318
 r7:c0e32b10 r6:c0a00ca8 r5:00000000 r4:c0e32b00
 register_framebuffer from sa1100fb_probe+0x334/0x420
 r9:00000000 r8:0000000d r7:00000004 r6:c07dfe08 r5:00000000 r4:c0e32b00
 sa1100fb_probe from platform_probe+0x4c/0xac
 r10:c07cb85c r9:c07cb87c r8:00000000 r7:00000000 r6:c0805abc r5:c07dfe18
 r4:00000000
 platform_probe from really_probe+0xc0/0x280
 r7:00000000 r6:c0805abc r5:c07dfe18 r4:00000000
 really_probe from __driver_probe_device+0x84/0xe4
 r7:00000000 r6:c07dfe18 r5:c0805abc r4:c07dfe18
 __driver_probe_device from driver_probe_device+0x4c/0x10c
 r5:60000153 r4:c0a04c6c
 driver_probe_device from __driver_attach+0x90/0x104
 r7:c080af60 r6:c045a7d0 r5:c0805abc r4:c07dfe18
 __driver_attach from bus_for_each_dev+0x80/0xcc
 r7:c080af60 r6:c045a7d0 r5:c0805abc r4:00000000
 bus_for_each_dev from driver_attach+0x20/0x28
 r6:00000000 r5:c0e5d340 r4:c0805abc
 driver_attach from bus_add_driver+0x140/0x1c8
 bus_add_driver from driver_register+0x7c/0x110
 r7:c07a4bc8 r6:c07bc340 r5:c0c19000 r4:c0805abc
 driver_register from __platform_driver_register+0x20/0x28
 r5:c0c19000 r4:c0818000
 __platform_driver_register from sa1100fb_init+0x28/0x3c
 sa1100fb_init from do_one_initcall+0x78/0x220
 do_one_initcall from kernel_init_freeable+0x180/0x1fc
 r10:c07cb85c r9:c07cb87c r8:c0818000 r7:c07a4bc8 r6:00000007 r5:c0c427a0
 r4:c07d2060
 kernel_init_freeable from kernel_init+0x18/0x10c
 r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0675804
 r4:00000000
 kernel_init from ret_from_fork+0x14/0x2c
Exception stack(0xe0809fb0 to 0xe0809ff8)
9fa0:                                     00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
 r5:c0675804 r4:00000000
Code: e24ba02c e0026323 e08a6106 e5166044 (e58c6000)
---[ end trace 00000000c08187d8 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Reboot failed -- System halted

---
# bad: [dd315b5800612e6913343524aa9b993f9a8bb0cf] Add linux-next specific files for 20220324
# good: [f443e374ae131c168a065ea1748feac6b2e76613] Linux 5.17
git bisect start 'HEAD' 'v5.17'
# good: [6788381e2f3c20c25cf7ab91df9cf0d6bec153f9] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
git bisect good 6788381e2f3c20c25cf7ab91df9cf0d6bec153f9
# bad: [59c7e0caa3e7bc21dd1b6c681c87d2b307f399ee] Merge branch 'drm-next' of git://git.freedesktop.org/git/drm/drm.git
git bisect bad 59c7e0caa3e7bc21dd1b6c681c87d2b307f399ee
# good: [4d17d43de9d186150b3289ce99d7a79fcff202f9] net: usb: asix: suspend embedded PHY if external is used
git bisect good 4d17d43de9d186150b3289ce99d7a79fcff202f9
# good: [6c64ae228f0826859c56711ce133aff037d6205f] Backmerge tag 'v5.17-rc6' into drm-next
git bisect good 6c64ae228f0826859c56711ce133aff037d6205f
# good: [01fd8d2522c49a333b0ee46ba19a6fedfc1c9a60] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
git bisect good 01fd8d2522c49a333b0ee46ba19a6fedfc1c9a60
# bad: [6de7e4f02640fba2ffa6ac04e2be13785d614175] Merge tag 'drm-msm-next-2022-03-01' of https://gitlab.freedesktop.org/drm/msm into drm-next
git bisect bad 6de7e4f02640fba2ffa6ac04e2be13785d614175
# bad: [c9e9ce0b6f85ac330adee912745048a0af5f315d] Merge tag 'drm-misc-next-2022-03-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
git bisect bad c9e9ce0b6f85ac330adee912745048a0af5f315d
# good: [e2573d5f2a5cebe789bbf415e484b589d8eebad7] drm/amd/display: limit unbounded requesting to 5k
git bisect good e2573d5f2a5cebe789bbf415e484b589d8eebad7
# good: [3c54c95bd917d43d12fe1b192df9aa4c5973449b] fbdev: Remove trailing whitespaces from cfbimgblt.c
git bisect good 3c54c95bd917d43d12fe1b192df9aa4c5973449b
# good: [ed6e76676b2657b71a0b9e5e847d96e4de0b394b] drm: rcar-du: lvds: Add r8a77961 support
git bisect good ed6e76676b2657b71a0b9e5e847d96e4de0b394b
# good: [66a8af1f6e3c10190dff14a5668661c092a2a85f] Merge tag 'drm/tegra/for-5.18-rc1' of https://gitlab.freedesktop.org/drm/tegra into drm-next
git bisect good 66a8af1f6e3c10190dff14a5668661c092a2a85f
# bad: [701920ca9822eb63b420b3bcb627f2c1ec759903] drm/ssd130x: remove redundant initialization of pointer mode
git bisect bad 701920ca9822eb63b420b3bcb627f2c1ec759903
# bad: [9ae2ac4d31a85ce59cc560d514a31b95f4ace154] drm: Add TODO item for optimizing format helpers
git bisect bad 9ae2ac4d31a85ce59cc560d514a31b95f4ace154
# bad: [0d03011894d23241db1a1cad5c12aede60897d5e] fbdev: Improve performance of cfb_imageblit()
git bisect bad 0d03011894d23241db1a1cad5c12aede60897d5e
# first bad commit: [0d03011894d23241db1a1cad5c12aede60897d5e] fbdev: Improve performance of cfb_imageblit()

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 14073 bytes --]

Hi

Am 24.03.22 um 20:11 schrieb Guenter Roeck:
> Hi,
> 
> On Wed, Feb 23, 2022 at 08:38:03PM +0100, Thomas Zimmermann wrote:
>> Improve the performance of cfb_imageblit() by manually unrolling
>> the inner blitting loop and moving some invariants out. The compiler
>> failed to do this automatically. This change keeps cfb_imageblit()
>> in sync with sys_imagebit().
>>
>> A microbenchmark measures the average number of CPU cycles
>> for cfb_imageblit() after a stabilizing period of a few minutes
>> (i7-4790, FullHD, simpledrm, kernel with debugging).
>>
>> cfb_imageblit(), new: 15724 cycles
>> cfb_imageblit(): old: 30566 cycles
>>
>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
>>
>> v3:
>> 	* fix commit description (Pekka)
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> 
> This patch causes crashes with arm mainstone, z2, and collie emulations.
> Reverting it fixes the problem.
> 
> collie crash log and bisect log attached.

Does it work if you apply the fixes at

https://patchwork.freedesktop.org/series/101321/

?

Best regards
Thomas

> 
> Guenter
> 
> ---
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address e090d000
> [e090d000] *pgd=c0c0b811c0c0b811, *pte=c0c0b000, *ppte=00000000
> Internal error: Oops: 807 [#1] ARM
> CPU: 0 PID: 1 Comm: swapper Not tainted 5.17.0-next-20220324 #1
> Hardware name: Sharp-Collie
> PC is at cfb_imageblit+0x58c/0x6e0
> LR is at 0x5
> pc : [<c040eab0>]    lr : [<00000005>]    psr: a0000153
> sp : e0809958  ip : e090d000  fp : e08099f4
> r10: e08099c8  r9 : c0c70600  r8 : ffff6802
> r7 : c0c6e000  r6 : 00000000  r5 : e08e7000  r4 : 00000280
> r3 : 00000020  r2 : 00000003  r1 : 00000002  r0 : 00000002
> Flags: NzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
> Control: 0000717f  Table: c0004000  DAC: 00000053
> Register r0 information: non-paged memory
> Register r1 information: non-paged memory
> Register r2 information: non-paged memory
> Register r3 information: non-paged memory
> Register r4 information: non-paged memory
> Register r5 information: 0-page vmalloc region starting at 0xe08e6000 allocated at dma_common_contiguous_remap+0x94/0xb0
> Register r6 information: NULL pointer
> Register r7 information: non-slab/vmalloc memory
> Register r8 information: non-paged memory
> Register r9 information: non-slab/vmalloc memory
> Register r10 information: 2-page vmalloc region starting at 0xe0808000 allocated at kernel_clone+0x78/0x4e4
> Register r11 information: 2-page vmalloc region starting at 0xe0808000 allocated at kernel_clone+0x78/0x4e4
> Register r12 information: 0-page vmalloc region starting at 0xe08e6000 allocated at dma_common_contiguous_remap+0x94/0xb0
> Process swapper (pid: 1, stack limit = 0x(ptrval))
> Stack: (0xe0809958 to 0xe080a000)
> 9940:                                                       80000153 0000005e
> 9960: dfb1b424 00000020 00000000 00000000 00000001 00000002 00000003 00000004
> 9980: dfb1b420 00000000 00000000 00000000 00000000 c067f338 e08099ab 00000026
> 99a0: 80000153 00000820 007fe178 c07db82c e08099d4 0000003e 00000820 c0e32b00
> 99c0: 00000006 c07db82c 00000001 c0da1e40 e0809a54 c0e32b00 00000006 00000001
> 99e0: 00000001 c0c6e000 e0809a34 e08099f8 c040a3f8 c040e530 00000006 00000001
> 9a00: c0e61920 c0da1e78 00000000 c0e61920 00000000 e0809a54 c06ad89c c0e32b00
> 9a20: c0da1e00 00000020 e0809acc e0809a38 c040a040 c040a26c e0809a7c 00000140
> 9a40: 00000002 00000002 00000001 00000007 00000000 00000039 00000001 c0da1e00
> 9a60: 00000000 00000000 00000000 00000004 00000006 00000007 00000000 00000001
> 9a80: c06ad89c 00000000 00000000 00000000 00000000 ffffffff ffffffff c07db82c
> 9aa0: e0809acc c0c0c3c0 c0e32b00 00000007 00000002 00000720 c0409cf0 00000028
> 9ac0: e0809afc e0809ad0 c040665c c0409cfc 00000000 00000000 c0c0c3c0 c0807584
> 9ae0: 00000000 00000000 ffffff60 c0c70000 e0809b1c e0809b00 c0439a50 c040656c
> 9b00: c0c0c3c0 00000000 00000000 00000000 e0809b54 e0809b20 c043a798 c0439a24
> 9b20: c04095c8 c0c6ff60 00000000 c07db82c e0809b54 c0c0c3c0 c0c6ff60 00000000
> 9b40: 00000000 ffffff60 e0809ba4 e0809b58 c0407254 c043a5ac e0809b7c e0809b68
> 9b60: c04145d8 00000000 00000000 00000000 00000720 00000000 00000050 c0c0c3c0
> 9b80: c0e32b00 c0e61920 00000050 00000028 c0a00df8 00000028 e0809bec e0809ba8
> 9ba0: c0407748 c0406f04 00000050 00000028 00000050 00000001 c0a02f70 00000000
> 9bc0: 00000000 c0c0c3c0 c0c0c624 00000000 c0a02f84 0000003e 00000000 c0a03080
> 9be0: e0809c0c e0809bf0 c0438b10 c040734c c0c0c3c0 c06affbc 00000001 c0a02f84
> 9c00: e0809c54 e0809c10 c043be28 c0438a80 0000003e 00000001 00000000 c0779d88
> 9c20: 00000000 00000001 c08075a8 c06affbc 00000000 00000001 00000000 0000003e
> 9c40: 00000001 c0a02f8c e0809c9c e0809c58 c043c6ec c043bc98 c08075a8 c077c29c
> 9c60: 00000001 00000000 c0e32b44 c0a03a58 c067f354 c0805a24 c0a00cc8 c0805a24
> 9c80: 00000000 c07dbabc c0e32da4 fffff000 e0809cb4 e0809ca0 c0405d5c c043c5d4
> 9ca0: c0a00dac 00000000 e0809cd4 e0809cb8 c0408f48 c0405cfc c0e32b00 00000000
> 9cc0: c0a00ca8 c0e32b10 e0809d44 e0809cd8 c03ff9e4 c0408e70 c0779a14 00000000
> 9ce0: c000ea7c 00000000 00000041 00000140 000000f0 00029e01 0000000b 0000001e
> 9d00: 00000002 00000000 00000005 00000001 00000003 00000000 00000020 c07db82c
> 9d20: c0e32b00 00000000 c07dfe08 00000004 0000000d 00000000 e0809d84 e0809d48
> 9d40: c040f550 c03ff7e8 00000004 c077a1b8 c0e32b00 c0180a04 c07dfe18 00000000
> 9d60: c07dfe18 c0805abc 00000000 00000000 c07cb87c c07cb85c e0809da4 e0809d88
> 9d80: c045c2c8 c040f228 00000000 c07dfe18 c0805abc 00000000 e0809dc4 e0809da8
> 9da0: c045a304 c045c288 c07dfe18 c0805abc c07dfe18 00000000 e0809ddc e0809dc8
> 9dc0: c045a548 c045a250 c0a04c6c 60000153 e0809e04 e0809de0 c045a5f4 c045a4d0
> 9de0: e0809e04 e0809df0 c07dfe18 c0805abc c045a7d0 c080af60 e0809e24 e0809e08
> 9e00: c045a860 c045a5b4 00000000 c0805abc c045a7d0 c080af60 e0809e54 e0809e28
> 9e20: c0458694 c045a7dc c0c30e20 c0c30dec c0c9f3b4 c07db82c c06559b8 c0805abc
> 9e40: c0e5d340 00000000 e0809e64 e0809e58 c045adf0 c0458620 e0809e8c e0809e68
> 9e60: c0458fb8 c045addc c0749e14 e0809e78 c0805abc c0c19000 c07bc340 c07a4bc8
> 9e80: e0809ea4 e0809e90 c045b684 c0458e84 c0818000 c0c19000 e0809eb4 e0809ea8
> 9ea0: c045d10c c045b614 e0809ec4 e0809eb8 c07bc368 c045d0f8 e0809f4c e0809ec8
> 9ec0: c07a821c c07bc34c e0809eec e0809ed8 c00374f4 c065f390 c0c427da c07a5600
> 9ee0: e0809f4c e0809ef0 c00376f4 c07a7448 e0809f03 00000006 00000006 00000000
> 9f00: 00000000 c07a743c c0793b5c c07a4bc8 00000dc0 c0c427cc c0c427d4 c07db82c
> 9f20: 00000000 c07d2060 c0c427a0 00000007 c07a4bc8 c0818000 c07cb87c c07cb85c
> 9f40: e0809f94 e0809f50 c07a85a0 c07a81b0 00000006 00000006 00000000 c07a743c
> 9f60: c0c19000 0000008c e0809f8c 00000000 c0675804 00000000 00000000 00000000
> 9f80: 00000000 00000000 e0809fac e0809f98 c067581c c07a842c 00000000 c0675804
> 9fa0: 00000000 e0809fb0 c0008328 c0675810 00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> Backtrace:
>   cfb_imageblit from soft_cursor+0x198/0x1fc
>   r10:c0c6e000 r9:00000001 r8:00000001 r7:00000006 r6:c0e32b00 r5:e0809a54
>   r4:c0da1e40
>   soft_cursor from bit_cursor+0x350/0x4fc
>   r10:00000020 r9:c0da1e00 r8:c0e32b00 r7:c06ad89c r6:e0809a54 r5:00000000
>   r4:c0e61920
>   bit_cursor from fbcon_cursor+0xfc/0x110
>   r10:00000028 r9:c0409cf0 r8:00000720 r7:00000002 r6:00000007 r5:c0e32b00
>   r4:c0c0c3c0
>   fbcon_cursor from hide_cursor+0x38/0xac
>   r9:c0c70000 r8:ffffff60 r7:00000000 r6:00000000 r5:c0807584 r4:c0c0c3c0
>   hide_cursor from redraw_screen+0x1f8/0x258
>   r7:00000000 r6:00000000 r5:00000000 r4:c0c0c3c0
>   redraw_screen from fbcon_prepare_logo+0x35c/0x448
>   r8:ffffff60 r7:00000000 r6:00000000 r5:c0c6ff60 r4:c0c0c3c0
>   fbcon_prepare_logo from fbcon_init+0x408/0x4f8
>   r10:00000028 r9:c0a00df8 r8:00000028 r7:00000050 r6:c0e61920 r5:c0e32b00
>   r4:c0c0c3c0
>   fbcon_init from visual_init+0x9c/0xe0
>   r10:c0a03080 r9:00000000 r8:0000003e r7:c0a02f84 r6:00000000 r5:c0c0c624
>   r4:c0c0c3c0
>   visual_init from do_bind_con_driver+0x19c/0x370
>   r7:c0a02f84 r6:00000001 r5:c06affbc r4:c0c0c3c0
>   do_bind_con_driver from do_take_over_console+0x124/0x1b8
>   r10:c0a02f8c r9:00000001 r8:0000003e r7:00000000 r6:00000001 r5:00000000
>   r4:c06affbc
>   do_take_over_console from do_fbcon_takeover+0x6c/0xcc
>   r10:fffff000 r9:c0e32da4 r8:c07dbabc r7:00000000 r6:c0805a24 r5:c0a00cc8
>   r4:c0805a24
>   do_fbcon_takeover from fbcon_fb_registered+0xe4/0x128
>   r5:00000000 r4:c0a00dac
>   fbcon_fb_registered from register_framebuffer+0x208/0x318
>   r7:c0e32b10 r6:c0a00ca8 r5:00000000 r4:c0e32b00
>   register_framebuffer from sa1100fb_probe+0x334/0x420
>   r9:00000000 r8:0000000d r7:00000004 r6:c07dfe08 r5:00000000 r4:c0e32b00
>   sa1100fb_probe from platform_probe+0x4c/0xac
>   r10:c07cb85c r9:c07cb87c r8:00000000 r7:00000000 r6:c0805abc r5:c07dfe18
>   r4:00000000
>   platform_probe from really_probe+0xc0/0x280
>   r7:00000000 r6:c0805abc r5:c07dfe18 r4:00000000
>   really_probe from __driver_probe_device+0x84/0xe4
>   r7:00000000 r6:c07dfe18 r5:c0805abc r4:c07dfe18
>   __driver_probe_device from driver_probe_device+0x4c/0x10c
>   r5:60000153 r4:c0a04c6c
>   driver_probe_device from __driver_attach+0x90/0x104
>   r7:c080af60 r6:c045a7d0 r5:c0805abc r4:c07dfe18
>   __driver_attach from bus_for_each_dev+0x80/0xcc
>   r7:c080af60 r6:c045a7d0 r5:c0805abc r4:00000000
>   bus_for_each_dev from driver_attach+0x20/0x28
>   r6:00000000 r5:c0e5d340 r4:c0805abc
>   driver_attach from bus_add_driver+0x140/0x1c8
>   bus_add_driver from driver_register+0x7c/0x110
>   r7:c07a4bc8 r6:c07bc340 r5:c0c19000 r4:c0805abc
>   driver_register from __platform_driver_register+0x20/0x28
>   r5:c0c19000 r4:c0818000
>   __platform_driver_register from sa1100fb_init+0x28/0x3c
>   sa1100fb_init from do_one_initcall+0x78/0x220
>   do_one_initcall from kernel_init_freeable+0x180/0x1fc
>   r10:c07cb85c r9:c07cb87c r8:c0818000 r7:c07a4bc8 r6:00000007 r5:c0c427a0
>   r4:c07d2060
>   kernel_init_freeable from kernel_init+0x18/0x10c
>   r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0675804
>   r4:00000000
>   kernel_init from ret_from_fork+0x14/0x2c
> Exception stack(0xe0809fb0 to 0xe0809ff8)
> 9fa0:                                     00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>   r5:c0675804 r4:00000000
> Code: e24ba02c e0026323 e08a6106 e5166044 (e58c6000)
> ---[ end trace 00000000c08187d8 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> Reboot failed -- System halted
> 
> ---
> # bad: [dd315b5800612e6913343524aa9b993f9a8bb0cf] Add linux-next specific files for 20220324
> # good: [f443e374ae131c168a065ea1748feac6b2e76613] Linux 5.17
> git bisect start 'HEAD' 'v5.17'
> # good: [6788381e2f3c20c25cf7ab91df9cf0d6bec153f9] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
> git bisect good 6788381e2f3c20c25cf7ab91df9cf0d6bec153f9
> # bad: [59c7e0caa3e7bc21dd1b6c681c87d2b307f399ee] Merge branch 'drm-next' of git://git.freedesktop.org/git/drm/drm.git
> git bisect bad 59c7e0caa3e7bc21dd1b6c681c87d2b307f399ee
> # good: [4d17d43de9d186150b3289ce99d7a79fcff202f9] net: usb: asix: suspend embedded PHY if external is used
> git bisect good 4d17d43de9d186150b3289ce99d7a79fcff202f9
> # good: [6c64ae228f0826859c56711ce133aff037d6205f] Backmerge tag 'v5.17-rc6' into drm-next
> git bisect good 6c64ae228f0826859c56711ce133aff037d6205f
> # good: [01fd8d2522c49a333b0ee46ba19a6fedfc1c9a60] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
> git bisect good 01fd8d2522c49a333b0ee46ba19a6fedfc1c9a60
> # bad: [6de7e4f02640fba2ffa6ac04e2be13785d614175] Merge tag 'drm-msm-next-2022-03-01' of https://gitlab.freedesktop.org/drm/msm into drm-next
> git bisect bad 6de7e4f02640fba2ffa6ac04e2be13785d614175
> # bad: [c9e9ce0b6f85ac330adee912745048a0af5f315d] Merge tag 'drm-misc-next-2022-03-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
> git bisect bad c9e9ce0b6f85ac330adee912745048a0af5f315d
> # good: [e2573d5f2a5cebe789bbf415e484b589d8eebad7] drm/amd/display: limit unbounded requesting to 5k
> git bisect good e2573d5f2a5cebe789bbf415e484b589d8eebad7
> # good: [3c54c95bd917d43d12fe1b192df9aa4c5973449b] fbdev: Remove trailing whitespaces from cfbimgblt.c
> git bisect good 3c54c95bd917d43d12fe1b192df9aa4c5973449b
> # good: [ed6e76676b2657b71a0b9e5e847d96e4de0b394b] drm: rcar-du: lvds: Add r8a77961 support
> git bisect good ed6e76676b2657b71a0b9e5e847d96e4de0b394b
> # good: [66a8af1f6e3c10190dff14a5668661c092a2a85f] Merge tag 'drm/tegra/for-5.18-rc1' of https://gitlab.freedesktop.org/drm/tegra into drm-next
> git bisect good 66a8af1f6e3c10190dff14a5668661c092a2a85f
> # bad: [701920ca9822eb63b420b3bcb627f2c1ec759903] drm/ssd130x: remove redundant initialization of pointer mode
> git bisect bad 701920ca9822eb63b420b3bcb627f2c1ec759903
> # bad: [9ae2ac4d31a85ce59cc560d514a31b95f4ace154] drm: Add TODO item for optimizing format helpers
> git bisect bad 9ae2ac4d31a85ce59cc560d514a31b95f4ace154
> # bad: [0d03011894d23241db1a1cad5c12aede60897d5e] fbdev: Improve performance of cfb_imageblit()
> git bisect bad 0d03011894d23241db1a1cad5c12aede60897d5e
> # first bad commit: [0d03011894d23241db1a1cad5c12aede60897d5e] fbdev: Improve performance of cfb_imageblit()

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 14073 bytes --]

Hi

Am 24.03.22 um 20:11 schrieb Guenter Roeck:
> Hi,
> 
> On Wed, Feb 23, 2022 at 08:38:03PM +0100, Thomas Zimmermann wrote:
>> Improve the performance of cfb_imageblit() by manually unrolling
>> the inner blitting loop and moving some invariants out. The compiler
>> failed to do this automatically. This change keeps cfb_imageblit()
>> in sync with sys_imagebit().
>>
>> A microbenchmark measures the average number of CPU cycles
>> for cfb_imageblit() after a stabilizing period of a few minutes
>> (i7-4790, FullHD, simpledrm, kernel with debugging).
>>
>> cfb_imageblit(), new: 15724 cycles
>> cfb_imageblit(): old: 30566 cycles
>>
>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
>>
>> v3:
>> 	* fix commit description (Pekka)
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> 
> This patch causes crashes with arm mainstone, z2, and collie emulations.
> Reverting it fixes the problem.
> 
> collie crash log and bisect log attached.

Does it work if you apply the fixes at

https://patchwork.freedesktop.org/series/101321/

?

Best regards
Thomas

> 
> Guenter
> 
> ---
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address e090d000
> [e090d000] *pgd=c0c0b811c0c0b811, *pte=c0c0b000, *ppte=00000000
> Internal error: Oops: 807 [#1] ARM
> CPU: 0 PID: 1 Comm: swapper Not tainted 5.17.0-next-20220324 #1
> Hardware name: Sharp-Collie
> PC is at cfb_imageblit+0x58c/0x6e0
> LR is at 0x5
> pc : [<c040eab0>]    lr : [<00000005>]    psr: a0000153
> sp : e0809958  ip : e090d000  fp : e08099f4
> r10: e08099c8  r9 : c0c70600  r8 : ffff6802
> r7 : c0c6e000  r6 : 00000000  r5 : e08e7000  r4 : 00000280
> r3 : 00000020  r2 : 00000003  r1 : 00000002  r0 : 00000002
> Flags: NzCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment none
> Control: 0000717f  Table: c0004000  DAC: 00000053
> Register r0 information: non-paged memory
> Register r1 information: non-paged memory
> Register r2 information: non-paged memory
> Register r3 information: non-paged memory
> Register r4 information: non-paged memory
> Register r5 information: 0-page vmalloc region starting at 0xe08e6000 allocated at dma_common_contiguous_remap+0x94/0xb0
> Register r6 information: NULL pointer
> Register r7 information: non-slab/vmalloc memory
> Register r8 information: non-paged memory
> Register r9 information: non-slab/vmalloc memory
> Register r10 information: 2-page vmalloc region starting at 0xe0808000 allocated at kernel_clone+0x78/0x4e4
> Register r11 information: 2-page vmalloc region starting at 0xe0808000 allocated at kernel_clone+0x78/0x4e4
> Register r12 information: 0-page vmalloc region starting at 0xe08e6000 allocated at dma_common_contiguous_remap+0x94/0xb0
> Process swapper (pid: 1, stack limit = 0x(ptrval))
> Stack: (0xe0809958 to 0xe080a000)
> 9940:                                                       80000153 0000005e
> 9960: dfb1b424 00000020 00000000 00000000 00000001 00000002 00000003 00000004
> 9980: dfb1b420 00000000 00000000 00000000 00000000 c067f338 e08099ab 00000026
> 99a0: 80000153 00000820 007fe178 c07db82c e08099d4 0000003e 00000820 c0e32b00
> 99c0: 00000006 c07db82c 00000001 c0da1e40 e0809a54 c0e32b00 00000006 00000001
> 99e0: 00000001 c0c6e000 e0809a34 e08099f8 c040a3f8 c040e530 00000006 00000001
> 9a00: c0e61920 c0da1e78 00000000 c0e61920 00000000 e0809a54 c06ad89c c0e32b00
> 9a20: c0da1e00 00000020 e0809acc e0809a38 c040a040 c040a26c e0809a7c 00000140
> 9a40: 00000002 00000002 00000001 00000007 00000000 00000039 00000001 c0da1e00
> 9a60: 00000000 00000000 00000000 00000004 00000006 00000007 00000000 00000001
> 9a80: c06ad89c 00000000 00000000 00000000 00000000 ffffffff ffffffff c07db82c
> 9aa0: e0809acc c0c0c3c0 c0e32b00 00000007 00000002 00000720 c0409cf0 00000028
> 9ac0: e0809afc e0809ad0 c040665c c0409cfc 00000000 00000000 c0c0c3c0 c0807584
> 9ae0: 00000000 00000000 ffffff60 c0c70000 e0809b1c e0809b00 c0439a50 c040656c
> 9b00: c0c0c3c0 00000000 00000000 00000000 e0809b54 e0809b20 c043a798 c0439a24
> 9b20: c04095c8 c0c6ff60 00000000 c07db82c e0809b54 c0c0c3c0 c0c6ff60 00000000
> 9b40: 00000000 ffffff60 e0809ba4 e0809b58 c0407254 c043a5ac e0809b7c e0809b68
> 9b60: c04145d8 00000000 00000000 00000000 00000720 00000000 00000050 c0c0c3c0
> 9b80: c0e32b00 c0e61920 00000050 00000028 c0a00df8 00000028 e0809bec e0809ba8
> 9ba0: c0407748 c0406f04 00000050 00000028 00000050 00000001 c0a02f70 00000000
> 9bc0: 00000000 c0c0c3c0 c0c0c624 00000000 c0a02f84 0000003e 00000000 c0a03080
> 9be0: e0809c0c e0809bf0 c0438b10 c040734c c0c0c3c0 c06affbc 00000001 c0a02f84
> 9c00: e0809c54 e0809c10 c043be28 c0438a80 0000003e 00000001 00000000 c0779d88
> 9c20: 00000000 00000001 c08075a8 c06affbc 00000000 00000001 00000000 0000003e
> 9c40: 00000001 c0a02f8c e0809c9c e0809c58 c043c6ec c043bc98 c08075a8 c077c29c
> 9c60: 00000001 00000000 c0e32b44 c0a03a58 c067f354 c0805a24 c0a00cc8 c0805a24
> 9c80: 00000000 c07dbabc c0e32da4 fffff000 e0809cb4 e0809ca0 c0405d5c c043c5d4
> 9ca0: c0a00dac 00000000 e0809cd4 e0809cb8 c0408f48 c0405cfc c0e32b00 00000000
> 9cc0: c0a00ca8 c0e32b10 e0809d44 e0809cd8 c03ff9e4 c0408e70 c0779a14 00000000
> 9ce0: c000ea7c 00000000 00000041 00000140 000000f0 00029e01 0000000b 0000001e
> 9d00: 00000002 00000000 00000005 00000001 00000003 00000000 00000020 c07db82c
> 9d20: c0e32b00 00000000 c07dfe08 00000004 0000000d 00000000 e0809d84 e0809d48
> 9d40: c040f550 c03ff7e8 00000004 c077a1b8 c0e32b00 c0180a04 c07dfe18 00000000
> 9d60: c07dfe18 c0805abc 00000000 00000000 c07cb87c c07cb85c e0809da4 e0809d88
> 9d80: c045c2c8 c040f228 00000000 c07dfe18 c0805abc 00000000 e0809dc4 e0809da8
> 9da0: c045a304 c045c288 c07dfe18 c0805abc c07dfe18 00000000 e0809ddc e0809dc8
> 9dc0: c045a548 c045a250 c0a04c6c 60000153 e0809e04 e0809de0 c045a5f4 c045a4d0
> 9de0: e0809e04 e0809df0 c07dfe18 c0805abc c045a7d0 c080af60 e0809e24 e0809e08
> 9e00: c045a860 c045a5b4 00000000 c0805abc c045a7d0 c080af60 e0809e54 e0809e28
> 9e20: c0458694 c045a7dc c0c30e20 c0c30dec c0c9f3b4 c07db82c c06559b8 c0805abc
> 9e40: c0e5d340 00000000 e0809e64 e0809e58 c045adf0 c0458620 e0809e8c e0809e68
> 9e60: c0458fb8 c045addc c0749e14 e0809e78 c0805abc c0c19000 c07bc340 c07a4bc8
> 9e80: e0809ea4 e0809e90 c045b684 c0458e84 c0818000 c0c19000 e0809eb4 e0809ea8
> 9ea0: c045d10c c045b614 e0809ec4 e0809eb8 c07bc368 c045d0f8 e0809f4c e0809ec8
> 9ec0: c07a821c c07bc34c e0809eec e0809ed8 c00374f4 c065f390 c0c427da c07a5600
> 9ee0: e0809f4c e0809ef0 c00376f4 c07a7448 e0809f03 00000006 00000006 00000000
> 9f00: 00000000 c07a743c c0793b5c c07a4bc8 00000dc0 c0c427cc c0c427d4 c07db82c
> 9f20: 00000000 c07d2060 c0c427a0 00000007 c07a4bc8 c0818000 c07cb87c c07cb85c
> 9f40: e0809f94 e0809f50 c07a85a0 c07a81b0 00000006 00000006 00000000 c07a743c
> 9f60: c0c19000 0000008c e0809f8c 00000000 c0675804 00000000 00000000 00000000
> 9f80: 00000000 00000000 e0809fac e0809f98 c067581c c07a842c 00000000 c0675804
> 9fa0: 00000000 e0809fb0 c0008328 c0675810 00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> Backtrace:
>   cfb_imageblit from soft_cursor+0x198/0x1fc
>   r10:c0c6e000 r9:00000001 r8:00000001 r7:00000006 r6:c0e32b00 r5:e0809a54
>   r4:c0da1e40
>   soft_cursor from bit_cursor+0x350/0x4fc
>   r10:00000020 r9:c0da1e00 r8:c0e32b00 r7:c06ad89c r6:e0809a54 r5:00000000
>   r4:c0e61920
>   bit_cursor from fbcon_cursor+0xfc/0x110
>   r10:00000028 r9:c0409cf0 r8:00000720 r7:00000002 r6:00000007 r5:c0e32b00
>   r4:c0c0c3c0
>   fbcon_cursor from hide_cursor+0x38/0xac
>   r9:c0c70000 r8:ffffff60 r7:00000000 r6:00000000 r5:c0807584 r4:c0c0c3c0
>   hide_cursor from redraw_screen+0x1f8/0x258
>   r7:00000000 r6:00000000 r5:00000000 r4:c0c0c3c0
>   redraw_screen from fbcon_prepare_logo+0x35c/0x448
>   r8:ffffff60 r7:00000000 r6:00000000 r5:c0c6ff60 r4:c0c0c3c0
>   fbcon_prepare_logo from fbcon_init+0x408/0x4f8
>   r10:00000028 r9:c0a00df8 r8:00000028 r7:00000050 r6:c0e61920 r5:c0e32b00
>   r4:c0c0c3c0
>   fbcon_init from visual_init+0x9c/0xe0
>   r10:c0a03080 r9:00000000 r8:0000003e r7:c0a02f84 r6:00000000 r5:c0c0c624
>   r4:c0c0c3c0
>   visual_init from do_bind_con_driver+0x19c/0x370
>   r7:c0a02f84 r6:00000001 r5:c06affbc r4:c0c0c3c0
>   do_bind_con_driver from do_take_over_console+0x124/0x1b8
>   r10:c0a02f8c r9:00000001 r8:0000003e r7:00000000 r6:00000001 r5:00000000
>   r4:c06affbc
>   do_take_over_console from do_fbcon_takeover+0x6c/0xcc
>   r10:fffff000 r9:c0e32da4 r8:c07dbabc r7:00000000 r6:c0805a24 r5:c0a00cc8
>   r4:c0805a24
>   do_fbcon_takeover from fbcon_fb_registered+0xe4/0x128
>   r5:00000000 r4:c0a00dac
>   fbcon_fb_registered from register_framebuffer+0x208/0x318
>   r7:c0e32b10 r6:c0a00ca8 r5:00000000 r4:c0e32b00
>   register_framebuffer from sa1100fb_probe+0x334/0x420
>   r9:00000000 r8:0000000d r7:00000004 r6:c07dfe08 r5:00000000 r4:c0e32b00
>   sa1100fb_probe from platform_probe+0x4c/0xac
>   r10:c07cb85c r9:c07cb87c r8:00000000 r7:00000000 r6:c0805abc r5:c07dfe18
>   r4:00000000
>   platform_probe from really_probe+0xc0/0x280
>   r7:00000000 r6:c0805abc r5:c07dfe18 r4:00000000
>   really_probe from __driver_probe_device+0x84/0xe4
>   r7:00000000 r6:c07dfe18 r5:c0805abc r4:c07dfe18
>   __driver_probe_device from driver_probe_device+0x4c/0x10c
>   r5:60000153 r4:c0a04c6c
>   driver_probe_device from __driver_attach+0x90/0x104
>   r7:c080af60 r6:c045a7d0 r5:c0805abc r4:c07dfe18
>   __driver_attach from bus_for_each_dev+0x80/0xcc
>   r7:c080af60 r6:c045a7d0 r5:c0805abc r4:00000000
>   bus_for_each_dev from driver_attach+0x20/0x28
>   r6:00000000 r5:c0e5d340 r4:c0805abc
>   driver_attach from bus_add_driver+0x140/0x1c8
>   bus_add_driver from driver_register+0x7c/0x110
>   r7:c07a4bc8 r6:c07bc340 r5:c0c19000 r4:c0805abc
>   driver_register from __platform_driver_register+0x20/0x28
>   r5:c0c19000 r4:c0818000
>   __platform_driver_register from sa1100fb_init+0x28/0x3c
>   sa1100fb_init from do_one_initcall+0x78/0x220
>   do_one_initcall from kernel_init_freeable+0x180/0x1fc
>   r10:c07cb85c r9:c07cb87c r8:c0818000 r7:c07a4bc8 r6:00000007 r5:c0c427a0
>   r4:c07d2060
>   kernel_init_freeable from kernel_init+0x18/0x10c
>   r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0675804
>   r4:00000000
>   kernel_init from ret_from_fork+0x14/0x2c
> Exception stack(0xe0809fb0 to 0xe0809ff8)
> 9fa0:                                     00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>   r5:c0675804 r4:00000000
> Code: e24ba02c e0026323 e08a6106 e5166044 (e58c6000)
> ---[ end trace 00000000c08187d8 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> Reboot failed -- System halted
> 
> ---
> # bad: [dd315b5800612e6913343524aa9b993f9a8bb0cf] Add linux-next specific files for 20220324
> # good: [f443e374ae131c168a065ea1748feac6b2e76613] Linux 5.17
> git bisect start 'HEAD' 'v5.17'
> # good: [6788381e2f3c20c25cf7ab91df9cf0d6bec153f9] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git
> git bisect good 6788381e2f3c20c25cf7ab91df9cf0d6bec153f9
> # bad: [59c7e0caa3e7bc21dd1b6c681c87d2b307f399ee] Merge branch 'drm-next' of git://git.freedesktop.org/git/drm/drm.git
> git bisect bad 59c7e0caa3e7bc21dd1b6c681c87d2b307f399ee
> # good: [4d17d43de9d186150b3289ce99d7a79fcff202f9] net: usb: asix: suspend embedded PHY if external is used
> git bisect good 4d17d43de9d186150b3289ce99d7a79fcff202f9
> # good: [6c64ae228f0826859c56711ce133aff037d6205f] Backmerge tag 'v5.17-rc6' into drm-next
> git bisect good 6c64ae228f0826859c56711ce133aff037d6205f
> # good: [01fd8d2522c49a333b0ee46ba19a6fedfc1c9a60] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
> git bisect good 01fd8d2522c49a333b0ee46ba19a6fedfc1c9a60
> # bad: [6de7e4f02640fba2ffa6ac04e2be13785d614175] Merge tag 'drm-msm-next-2022-03-01' of https://gitlab.freedesktop.org/drm/msm into drm-next
> git bisect bad 6de7e4f02640fba2ffa6ac04e2be13785d614175
> # bad: [c9e9ce0b6f85ac330adee912745048a0af5f315d] Merge tag 'drm-misc-next-2022-03-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
> git bisect bad c9e9ce0b6f85ac330adee912745048a0af5f315d
> # good: [e2573d5f2a5cebe789bbf415e484b589d8eebad7] drm/amd/display: limit unbounded requesting to 5k
> git bisect good e2573d5f2a5cebe789bbf415e484b589d8eebad7
> # good: [3c54c95bd917d43d12fe1b192df9aa4c5973449b] fbdev: Remove trailing whitespaces from cfbimgblt.c
> git bisect good 3c54c95bd917d43d12fe1b192df9aa4c5973449b
> # good: [ed6e76676b2657b71a0b9e5e847d96e4de0b394b] drm: rcar-du: lvds: Add r8a77961 support
> git bisect good ed6e76676b2657b71a0b9e5e847d96e4de0b394b
> # good: [66a8af1f6e3c10190dff14a5668661c092a2a85f] Merge tag 'drm/tegra/for-5.18-rc1' of https://gitlab.freedesktop.org/drm/tegra into drm-next
> git bisect good 66a8af1f6e3c10190dff14a5668661c092a2a85f
> # bad: [701920ca9822eb63b420b3bcb627f2c1ec759903] drm/ssd130x: remove redundant initialization of pointer mode
> git bisect bad 701920ca9822eb63b420b3bcb627f2c1ec759903
> # bad: [9ae2ac4d31a85ce59cc560d514a31b95f4ace154] drm: Add TODO item for optimizing format helpers
> git bisect bad 9ae2ac4d31a85ce59cc560d514a31b95f4ace154
> # bad: [0d03011894d23241db1a1cad5c12aede60897d5e] fbdev: Improve performance of cfb_imageblit()
> git bisect bad 0d03011894d23241db1a1cad5c12aede60897d5e
> # first bad commit: [0d03011894d23241db1a1cad5c12aede60897d5e] fbdev: Improve performance of cfb_imageblit()

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Guenter Roeck]

On 3/24/22 12:18, Thomas Zimmermann wrote:
> Hi
> 
> Am 24.03.22 um 20:11 schrieb Guenter Roeck:
>> Hi,
>>
>> On Wed, Feb 23, 2022 at 08:38:03PM +0100, Thomas Zimmermann wrote:
>>> Improve the performance of cfb_imageblit() by manually unrolling
>>> the inner blitting loop and moving some invariants out. The compiler
>>> failed to do this automatically. This change keeps cfb_imageblit()
>>> in sync with sys_imagebit().
>>>
>>> A microbenchmark measures the average number of CPU cycles
>>> for cfb_imageblit() after a stabilizing period of a few minutes
>>> (i7-4790, FullHD, simpledrm, kernel with debugging).
>>>
>>> cfb_imageblit(), new: 15724 cycles
>>> cfb_imageblit(): old: 30566 cycles
>>>
>>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
>>>
>>> v3:
>>>     * fix commit description (Pekka)
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>
>> This patch causes crashes with arm mainstone, z2, and collie emulations.
>> Reverting it fixes the problem.
>>
>> collie crash log and bisect log attached.
> 
> Does it work if you apply the fixes at
> 
> https://patchwork.freedesktop.org/series/101321/
> 
> ?
> 

Yes, it does, specifically the cfb related patch. I sent a Tested-by:.

Thanks,
Guenter

Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()

[Guenter Roeck]

On 3/24/22 12:18, Thomas Zimmermann wrote:
> Hi
> 
> Am 24.03.22 um 20:11 schrieb Guenter Roeck:
>> Hi,
>>
>> On Wed, Feb 23, 2022 at 08:38:03PM +0100, Thomas Zimmermann wrote:
>>> Improve the performance of cfb_imageblit() by manually unrolling
>>> the inner blitting loop and moving some invariants out. The compiler
>>> failed to do this automatically. This change keeps cfb_imageblit()
>>> in sync with sys_imagebit().
>>>
>>> A microbenchmark measures the average number of CPU cycles
>>> for cfb_imageblit() after a stabilizing period of a few minutes
>>> (i7-4790, FullHD, simpledrm, kernel with debugging).
>>>
>>> cfb_imageblit(), new: 15724 cycles
>>> cfb_imageblit(): old: 30566 cycles
>>>
>>> In the optimized case, cfb_imageblit() is now ~2x faster than before.
>>>
>>> v3:
>>>     * fix commit description (Pekka)
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>
>> This patch causes crashes with arm mainstone, z2, and collie emulations.
>> Reverting it fixes the problem.
>>
>> collie crash log and bisect log attached.
> 
> Does it work if you apply the fixes at
> 
> https://patchwork.freedesktop.org/series/101321/
> 
> ?
> 

Yes, it does, specifically the cfb related patch. I sent a Tested-by:.

Thanks,
Guenter