2.6.9-rc1: scrolling with tdfxfb 5 times slower

2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Paolo Ornati]

The recent changes in frame buffer code seems to affect performance of 
scrolling on my system:

Voodoo Banshee (tdfxfb)

CONFIG:
#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_3DFX=y
# CONFIG_FB_3DFX_ACCEL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y


Tests with "linux/MAINTAINERS" (time cat MAINTAINERS)
2.6.8.1
	real    0m2.625s
	user    0m0.000s
	sys     0m2.621s

2.6.9-rc1
	real    0m13.528s
	user    0m0.000s
	sys     0m13.553s


Also many -mm kernels are affected... this is obvious because these patches 
come from Andrew's tree ;-)

Any ideas?

-- 
	Paolo Ornati
	Gentoo Linux (kernel 2.6.9-rc1)

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Antonino A. Daplas]

On Wednesday 01 September 2004 03:33, Paolo Ornati wrote:

> Tests with "linux/MAINTAINERS" (time cat MAINTAINERS)
> 2.6.8.1
> 	real    0m2.625s
> 	user    0m0.000s
> 	sys     0m2.621s
>
> 2.6.9-rc1
> 	real    0m13.528s
> 	user    0m0.000s
> 	sys     0m13.553s
>

Open drivers/video/tdfxfb.c, change the following (at line 1278):

info->flags		= FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;

to

info->flags		= FBINFO_DEFAULT;

Let me know of the results.

Tony

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Paolo Ornati]

On Tuesday 31 August 2004 22:28, Antonino A. Daplas wrote:
>
> Open drivers/video/tdfxfb.c, change the following (at line 1278):
>
> info->flags		= FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
>
> to
>
> info->flags		= FBINFO_DEFAULT;
>

The scrolling speed doesn't change.

-- 
	Paolo Ornati
	Gentoo Linux (kernel 2.6.8-gentoo-r3)

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Antonino A. Daplas]

On Wednesday 01 September 2004 03:33, Paolo Ornati wrote:
> Tests with "linux/MAINTAINERS" (time cat MAINTAINERS)
> 2.6.8.1
> 	real    0m2.625s
> 	user    0m0.000s
> 	sys     0m2.621s
>
> 2.6.9-rc1
> 	real    0m13.528s
> 	user    0m0.000s
> 	sys     0m13.553s
>
>
> Also many -mm kernels are affected... this is obvious because these patches
> come from Andrew's tree ;-)
>

Try this patch also, but select Y for CONFIG_FB_3DFX_ACCEL.  You also need
to revert info->flags to FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;

Tony

diff -uprN linux-2.6.9-rc1-mm1-orig/drivers/video/tdfxfb.c linux-2.6.9-rc1-mm1/drivers/video/tdfxfb.c
--- linux-2.6.9-rc1-mm1-orig/drivers/video/tdfxfb.c	2004-08-30 19:39:19.000000000 +0800
+++ linux-2.6.9-rc1-mm1/drivers/video/tdfxfb.c	2004-09-01 07:23:12.855078672 +0800
@@ -168,7 +168,6 @@ static int banshee_wait_idle(struct fb_i
 static void tdfxfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
 static void tdfxfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);  
 static void tdfxfb_imageblit(struct fb_info *info, const struct fb_image *image); 
-static int tdfxfb_cursor(struct fb_info *info, struct fb_cursor *cursor);
 #endif /* CONFIG_FB_3DFX_ACCEL */
 
 static struct fb_ops tdfxfb_ops = {
@@ -183,13 +182,12 @@ static struct fb_ops tdfxfb_ops = {
 	.fb_fillrect	= tdfxfb_fillrect,
 	.fb_copyarea	= tdfxfb_copyarea,
 	.fb_imageblit	= tdfxfb_imageblit,
-	.fb_cursor	= tdfxfb_cursor,
 #else
 	.fb_fillrect	= cfb_fillrect,
 	.fb_copyarea	= cfb_copyarea,
 	.fb_imageblit	= cfb_imageblit,
-	.fb_cursor	= soft_cursor,
 #endif
+	.fb_cursor	= soft_cursor,
 };
 
 /*
@@ -1030,7 +1028,9 @@ static void tdfxfb_imageblit(struct fb_i
 	}
 	banshee_wait_idle(info);
 }
+#endif /* CONFIG_FB_3DFX_ACCEL */
 
+#ifdef TDFX_HARDWARE_CURSOR
 static int tdfxfb_cursor(struct fb_info *info, struct fb_cursor *cursor)
 {
 	struct tdfx_par *par = (struct tdfx_par *) info->par;
@@ -1167,7 +1167,7 @@ static int tdfxfb_cursor(struct fb_info 
 	spin_unlock_irqrestore(&par->DAClock, flags);
 	return 0;
 }
-#endif /* CONFIG_FB_3DFX_ACCEL */
+#endif
 
 /**
  *      tdfxfb_probe - Device Initializiation

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Paolo Ornati]

On Wednesday 01 September 2004 01:29, Antonino A. Daplas wrote:
> On Wednesday 01 September 2004 03:33, Paolo Ornati wrote:
> > Tests with "linux/MAINTAINERS" (time cat MAINTAINERS)
> > 2.6.8.1
> > 	real    0m2.625s
> > 	user    0m0.000s
> > 	sys     0m2.621s
> >
> > 2.6.9-rc1
> > 	real    0m13.528s
> > 	user    0m0.000s
> > 	sys     0m13.553s
> >
> >
> > Also many -mm kernels are affected... this is obvious because these
> > patches come from Andrew's tree ;-)
>
> Try this patch also, but select Y for CONFIG_FB_3DFX_ACCEL.  You also
> need to revert info->flags to FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
>
> Tony
>
> diff -uprN linux-2.6.9-rc1-mm1-orig/drivers/video/tdfxfb.c
> linux-2.6.9-rc1-mm1/drivers/video/tdfxfb.c ---
> linux-2.6.9-rc1-mm1-orig/drivers/video/tdfxfb.c	2004-08-30
> 19:39:19.000000000 +0800 +++
> linux-2.6.9-rc1-mm1/drivers/video/tdfxfb.c	2004-09-01 07:23:12.855078672
> +0800 @@ -168,7 +168,6 @@ static int banshee_wait_idle(struct fb_i
>  static void tdfxfb_fillrect(struct fb_info *info, const struct
> fb_fillrect *rect); static void tdfxfb_copyarea(struct fb_info *info,
> const struct fb_copyarea *area); static void tdfxfb_imageblit(struct
> fb_info *info, const struct fb_image *image); -static int
> tdfxfb_cursor(struct fb_info *info, struct fb_cursor *cursor); #endif /*
> CONFIG_FB_3DFX_ACCEL */
>
>  static struct fb_ops tdfxfb_ops = {
> @@ -183,13 +182,12 @@ static struct fb_ops tdfxfb_ops = {
>  	.fb_fillrect	= tdfxfb_fillrect,
>  	.fb_copyarea	= tdfxfb_copyarea,
>  	.fb_imageblit	= tdfxfb_imageblit,
> -	.fb_cursor	= tdfxfb_cursor,
>  #else
>  	.fb_fillrect	= cfb_fillrect,
>  	.fb_copyarea	= cfb_copyarea,
>  	.fb_imageblit	= cfb_imageblit,
> -	.fb_cursor	= soft_cursor,
>  #endif
> +	.fb_cursor	= soft_cursor,
>  };
>
>  /*
> @@ -1030,7 +1028,9 @@ static void tdfxfb_imageblit(struct fb_i
>  	}
>  	banshee_wait_idle(info);
>  }
> +#endif /* CONFIG_FB_3DFX_ACCEL */
>
> +#ifdef TDFX_HARDWARE_CURSOR
>  static int tdfxfb_cursor(struct fb_info *info, struct fb_cursor *cursor)
>  {
>  	struct tdfx_par *par = (struct tdfx_par *) info->par;
> @@ -1167,7 +1167,7 @@ static int tdfxfb_cursor(struct fb_info
>  	spin_unlock_irqrestore(&par->DAClock, flags);
>  	return 0;
>  }
> -#endif /* CONFIG_FB_3DFX_ACCEL */
> +#endif
>
>  /**
>   *      tdfxfb_probe - Device Initializiation

Ok, with this patch and CONFIG_FB_3DFX_ACCEL=y the scrolling speed comes 
back (only a bit slower than with 2.6.8.1 without CONFIG_FB_3DFX_ACCEL):

$ time cat MAINTAINERS: ~2.67s

Another interesting thing is that if I enable CONFIG_FB_3DFX_ACCEL without 
your patch the screen becomes black and the kernel stop working at boot 
time (when the mode switch happens).

-- 
	Paolo Ornati
	Gentoo Linux (kernel 2.6.8-gentoo-r3)

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Antonino A. Daplas]

On Wednesday 01 September 2004 15:20, Paolo Ornati wrote:

> Ok, with this patch and CONFIG_FB_3DFX_ACCEL=y the scrolling speed comes
> back (only a bit slower than with 2.6.8.1 without CONFIG_FB_3DFX_ACCEL):
>
> $ time cat MAINTAINERS: ~2.67s

Ok.  However, I'm still wondering at the scrolling speed, it's a bit slower
than what I would expect (I get < 1 second with vesafb which is completely
unaccelerated).  

Did you set info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN?
Do you use the 'nopan' boot option?   

Because if you answer yes to the first question and no to the second, that
means that tdfxfb_pan_display() is probably broken.

BTW, what does fbset -i say, and what's your hardware setup?

>
> Another interesting thing is that if I enable CONFIG_FB_3DFX_ACCEL without
> your patch the screen becomes black and the kernel stop working at boot
> time (when the mode switch happens).

tdfxfb_cursor() is broken, so I disabled that.  It's the reason your machine
hangs at boot time if CONFIG_FB_3DFX_ACCEL is set to y.

Tony

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Antonino A. Daplas]

On Wednesday 01 September 2004 18:21, Antonino A. Daplas wrote:
> On Wednesday 01 September 2004 15:20, Paolo Ornati wrote:
> > Ok, with this patch and CONFIG_FB_3DFX_ACCEL=y the scrolling speed comes
> > back (only a bit slower than with 2.6.8.1 without CONFIG_FB_3DFX_ACCEL):
> >
> > $ time cat MAINTAINERS: ~2.67s
>
> Ok.  However, I'm still wondering at the scrolling speed, it's a bit slower
> than what I would expect (I get < 1 second with vesafb which is completely
> unaccelerated).
>

Ok, I think I know why the scrolling speed is too slow, the driver is not
maximizing the extra memory of the framebuffer.

This patch sets info->var.yres_virtual to the maximum upon driver load. If
this works, it's possible to get sub-1 second scrolling speed.

Reverse the previous patch first, then apply this patch.

Tony
---

diff -uprN linux-2.6.9-rc1-mm1-orig/drivers/video/tdfxfb.c linux-2.6.9-rc1-mm1/drivers/video/tdfxfb.c
--- linux-2.6.9-rc1-mm1-orig/drivers/video/tdfxfb.c	2004-08-30 19:39:19.000000000 +0800
+++ linux-2.6.9-rc1-mm1/drivers/video/tdfxfb.c	2004-09-01 18:42:44.833205600 +0800
@@ -168,7 +168,6 @@ static int banshee_wait_idle(struct fb_i
 static void tdfxfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
 static void tdfxfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);  
 static void tdfxfb_imageblit(struct fb_info *info, const struct fb_image *image); 
-static int tdfxfb_cursor(struct fb_info *info, struct fb_cursor *cursor);
 #endif /* CONFIG_FB_3DFX_ACCEL */
 
 static struct fb_ops tdfxfb_ops = {
@@ -183,13 +182,12 @@ static struct fb_ops tdfxfb_ops = {
 	.fb_fillrect	= tdfxfb_fillrect,
 	.fb_copyarea	= tdfxfb_copyarea,
 	.fb_imageblit	= tdfxfb_imageblit,
-	.fb_cursor	= tdfxfb_cursor,
 #else
 	.fb_fillrect	= cfb_fillrect,
 	.fb_copyarea	= cfb_copyarea,
 	.fb_imageblit	= cfb_imageblit,
-	.fb_cursor	= soft_cursor,
 #endif
+	.fb_cursor	= soft_cursor,
 };
 
 /*
@@ -502,15 +500,11 @@ static int tdfxfb_check_var(struct fb_va
 		return -EINVAL;
 	}
 
-	if (var->xres != var->xres_virtual) {
-		DPRINTK("virtual x resolution != physical x resolution not supported\n");
-		return -EINVAL;
-	}
+	if (var->xres != var->xres_virtual)
+		var->xres_virtual = var->xres;
 
-	if (var->yres > var->yres_virtual) {
-		DPRINTK("virtual y resolution < physical y resolution not possible\n");
-		return -EINVAL;
-	}
+	if (var->yres > var->yres_virtual)
+		var->yres_virtual = var->yres;
 
 	if (var->xoffset) {
 		DPRINTK("xoffset not supported\n");
@@ -539,9 +533,12 @@ static int tdfxfb_check_var(struct fb_va
 	}
   
 	if (lpitch * var->yres_virtual > info->fix.smem_len) {
-		DPRINTK("no memory for screen (%ux%ux%u)\n",
-		var->xres, var->yres_virtual, var->bits_per_pixel);
-		return -EINVAL;
+		var->yres_virtual = info->fix.smem_len/lpitch;
+		if (var->yres_virtual < var->yres) {
+			DPRINTK("no memory for screen (%ux%ux%u)\n",
+			var->xres, var->yres_virtual, var->bits_per_pixel);
+			return -EINVAL;
+		}
 	}
   
 	if (PICOS2KHZ(var->pixclock) > par->max_pixclock) {
@@ -1030,7 +1027,9 @@ static void tdfxfb_imageblit(struct fb_i
 	}
 	banshee_wait_idle(info);
 }
+#endif /* CONFIG_FB_3DFX_ACCEL */
 
+#ifdef TDFX_HARDWARE_CURSOR
 static int tdfxfb_cursor(struct fb_info *info, struct fb_cursor *cursor)
 {
 	struct tdfx_par *par = (struct tdfx_par *) info->par;
@@ -1167,7 +1166,7 @@ static int tdfxfb_cursor(struct fb_info 
 	spin_unlock_irqrestore(&par->DAClock, flags);
 	return 0;
 }
-#endif /* CONFIG_FB_3DFX_ACCEL */
+#endif
 
 /**
  *      tdfxfb_probe - Device Initializiation
@@ -1183,7 +1182,7 @@ static int __devinit tdfxfb_probe(struct
 {
 	struct tdfx_par *default_par;
 	struct fb_info *info;
-	int size, err;
+	int size, err, lpitch;
 
 	if ((err = pci_enable_device(pdev))) {
 		printk(KERN_WARNING "tdfxfb: Can't enable pdev: %d\n", err);
@@ -1288,6 +1287,12 @@ static int __devinit tdfxfb_probe(struct
 	if (!err || err == 4)
 		info->var = tdfx_var;
 
+	/* maximize virtual vertical length */
+	lpitch = info->var.xres_virtual * ((info->var.bits_per_pixel + 7) >> 3);
+	info->var.yres_virtual = info->fix.smem_len/lpitch;
+	if (info->var.yres_virtual < info->var.yres)
+		goto out_err;
+
 	if (fb_alloc_cmap(&info->cmap, 256, 0) < 0) {
 		printk(KERN_WARNING "tdfxfb: Can't allocate color map\n");
 		goto out_err;

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Paolo Ornati]

On Wednesday 01 September 2004 12:51, Antonino A. Daplas wrote:
> On Wednesday 01 September 2004 18:21, Antonino A. Daplas wrote:
> > On Wednesday 01 September 2004 15:20, Paolo Ornati wrote:
> > > Ok, with this patch and CONFIG_FB_3DFX_ACCEL=y the scrolling speed
> > > comes back (only a bit slower than with 2.6.8.1 without
> > > CONFIG_FB_3DFX_ACCEL):
> > >
> > > $ time cat MAINTAINERS: ~2.67s
> >
> > Ok.  However, I'm still wondering at the scrolling speed, it's a bit
> > slower than what I would expect (I get < 1 second with vesafb which is
> > completely unaccelerated).
>
> Ok, I think I know why the scrolling speed is too slow, the driver is not
> maximizing the extra memory of the framebuffer.
>
> This patch sets info->var.yres_virtual to the maximum upon driver load.
> If this works, it's possible to get sub-1 second scrolling speed.
>
> Reverse the previous patch first, then apply this patch.

Results for 2.6.9-rc1 + your patch (time cat MAINTAINERS):

CONFIG_FB_3DFX_ACCEL=n
~1.27 s

CONFIG_FB_3DFX_ACCEL=y
~0.18 s

BUT with CONFIG_FB_3DFX_ACCEL enabled I get strange video 
"corruptions" (like bitmaps with random colors) that go away simply 
swithcing to another console and than back to the previous.

-- 
	Paolo Ornati
	Gentoo Linux (kernel 2.6.9-rc1)

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Antonino A. Daplas]

On Wednesday 01 September 2004 19:55, Paolo Ornati wrote:
> > This patch sets info->var.yres_virtual to the maximum upon driver load.
> > If this works, it's possible to get sub-1 second scrolling speed.
> >
> > Reverse the previous patch first, then apply this patch.
>
> Results for 2.6.9-rc1 + your patch (time cat MAINTAINERS):
>
> CONFIG_FB_3DFX_ACCEL=n
> ~1.27 s
>
> CONFIG_FB_3DFX_ACCEL=y
> ~0.18 s
>
> BUT with CONFIG_FB_3DFX_ACCEL enabled I get strange video
> "corruptions" (like bitmaps with random colors) that go away simply
> swithcing to another console and than back to the previous.

Might be a clipping problem?  Maybe we need to set an upper limit
to vyres, don't know for sure.  

Try doing an fbset -vyres 800, then keep doubling the number until
you get the artifacts.  If possible, do it for other bpp.

Tony 

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Paolo Ornati]

On Wednesday 01 September 2004 22:10, Antonino A. Daplas wrote:
> On Wednesday 01 September 2004 19:55, Paolo Ornati wrote:
> > > This patch sets info->var.yres_virtual to the maximum upon driver
> > > load. If this works, it's possible to get sub-1 second scrolling
> > > speed.
> > >
> > > Reverse the previous patch first, then apply this patch.
> >
> > Results for 2.6.9-rc1 + your patch (time cat MAINTAINERS):
> >
> > CONFIG_FB_3DFX_ACCEL=n
> > ~1.27 s
> >
> > CONFIG_FB_3DFX_ACCEL=y
> > ~0.18 s
> >
> > BUT with CONFIG_FB_3DFX_ACCEL enabled I get strange video
> > "corruptions" (like bitmaps with random colors) that go away simply
> > swithcing to another console and than back to the previous.
>
> Might be a clipping problem?  Maybe we need to set an upper limit
> to vyres, don't know for sure.
>
> Try doing an fbset -vyres 800, then keep doubling the number until
> you get the artifacts.  If possible, do it for other bpp.

Doing some tests I've discovered that BPP doesn't influence this behavior 
(kernel 2.6.9-rc1 + your patch, CONFIG_FB_3DFX_ACCEL=y):

BPP   800    1600    3200    6400	<-- VYRES
8         OK       OK       OK       X
16       OK       OK       OK       X
24       OK       OK       OK       X
32       OK       OK       OK       X

The upper limit for VYRES (after a lot of tests) seems to be around 
4100/4200 (with 4100 all seems OK while with 4200 there are some 
corruptions). This is the same for all BPP.

I don't understand why I have this problem only with 
CONFIG_FB_3DFX_ACCEL=y...

-- 
	Paolo Ornati
	Gentoo Linux (kernel 2.6.8-gentoo-r3)

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Antonino A. Daplas]

On Thursday 02 September 2004 17:23, Paolo Ornati wrote:
> > Try doing an fbset -vyres 800, then keep doubling the number until
> > you get the artifacts.  If possible, do it for other bpp.
>
> Doing some tests I've discovered that BPP doesn't influence this behavior
> (kernel 2.6.9-rc1 + your patch, CONFIG_FB_3DFX_ACCEL=y):
>
> BPP   800    1600    3200    6400	<-- VYRES
> 8         OK       OK       OK       X
> 16       OK       OK       OK       X
> 24       OK       OK       OK       X
> 32       OK       OK       OK       X
>
> The upper limit for VYRES (after a lot of tests) seems to be around
> 4100/4200 (with 4100 all seems OK while with 4200 there are some
> corruptions). This is the same for all BPP.

Ok, on driver load, we'll just set vyres to 4096 if accel is enabled, and
maximum if accel is disabled, until someone with more intimate knowledge of
the hardware provides a definitive fix. Still, if the user so chooses, fbset
can still be used to adjust vyres to any value. 

Just to finalize everything, 2 more things:

1. Does changing the resolution affect the vyres upper limit?

2. What happens if you comment out banshee_wait_idle in tdfxfb_fillrect,
tdfxfb_copyarea and tdfxfb_imageblit?  Scrolling should go faster but will
removing it cause additional screen corruption?

>
> I don't understand why I have this problem only with
> CONFIG_FB_3DFX_ACCEL=y...

No idea.  But I've seen this particular problem with several cards when 2D
acceleration is enabled, so it's not unique to tdfxfb. In one case, this
was caused by an upper limit to the clipping rectangle, and in another, was
due to the rendering and display pipeline being shared.

Tony

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Paolo Ornati]

On Thursday 02 September 2004 14:20, Antonino A. Daplas wrote:
>
> Just to finalize everything, 2 more things:
>
> 1. Does changing the resolution affect the vyres upper limit?

I have tried with 640x480, 800x600 and 1024x768 and the upper limit seems 
the same (I've also tried some combinations of resolution / BPP)

>
> 2. What happens if you comment out banshee_wait_idle in tdfxfb_fillrect,
> tdfxfb_copyarea and tdfxfb_imageblit?  Scrolling should go faster but
> will removing it cause additional screen corruption?

scrolling is a bit faster and I don't notice any additional screen 
corruption

time cat MAINTAINERS (2.6.9-rc1 + your patch / 800x600 8bpp / YRES 3200)

normal: ~0.19
without banshee_wait_idle in the three functions: ~0.12 

-- 
	Paolo Ornati
	Gentoo Linux (kernel 2.6.8-gentoo-r3)

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Antonino A. Daplas]

On Friday 03 September 2004 01:10, Paolo Ornati wrote:
> On Thursday 02 September 2004 14:20, Antonino A. Daplas wrote:
> > Just to finalize everything, 2 more things:
> >
> > 1. Does changing the resolution affect the vyres upper limit?
>
> I have tried with 640x480, 800x600 and 1024x768 and the upper limit seems
> the same (I've also tried some combinations of resolution / BPP)
>
> > 2. What happens if you comment out banshee_wait_idle in tdfxfb_fillrect,
> > tdfxfb_copyarea and tdfxfb_imageblit?  Scrolling should go faster but
> > will removing it cause additional screen corruption?
>
> scrolling is a bit faster and I don't notice any additional screen
> corruption
>
> time cat MAINTAINERS (2.6.9-rc1 + your patch / 800x600 8bpp / YRES 3200)
>
> normal: ~0.19
> without banshee_wait_idle in the three functions: ~0.12

Thanks for all the help.  I'll finalize a patch soon.

Tony

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Antonino A. Daplas]

On Wednesday 01 September 2004 19:55, Paolo Ornati wrote:
> > Ok, I think I know why the scrolling speed is too slow, the driver is not
> > maximizing the extra memory of the framebuffer.
> >
> > This patch sets info->var.yres_virtual to the maximum upon driver load.
> > If this works, it's possible to get sub-1 second scrolling speed.
> >
> > Reverse the previous patch first, then apply this patch.
>
> Results for 2.6.9-rc1 + your patch (time cat MAINTAINERS):
>
> CONFIG_FB_3DFX_ACCEL=n
> ~1.27 s
>
> CONFIG_FB_3DFX_ACCEL=y
> ~0.18 s
>
> BUT with CONFIG_FB_3DFX_ACCEL enabled I get strange video
> "corruptions" (like bitmaps with random colors) that go away simply
> swithcing to another console and than back to the previous.

And another suggestion:

Try to comment out FBINFO_HWACCEL_COPYAREA.

Tony

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Paolo Ornati]

On Wednesday 01 September 2004 22:20, Antonino A. Daplas wrote:
> >
> > BUT with CONFIG_FB_3DFX_ACCEL enabled I get strange video
> > "corruptions" (like bitmaps with random colors) that go away simply
> > swithcing to another console and than back to the previous.
>
> And another suggestion:
>
> Try to comment out FBINFO_HWACCEL_COPYAREA.

this has the only effect of slowing down the scrolling (not too much)... so 
the "copy area" routine of tdfxfb driver seems fine

-- 
	Paolo Ornati
	Gentoo Linux (kernel 2.6.8-gentoo-r3)

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[Paolo Ornati]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

On Wednesday 01 September 2004 12:21, Antonino A. Daplas wrote:
> On Wednesday 01 September 2004 15:20, Paolo Ornati wrote:
> > Ok, with this patch and CONFIG_FB_3DFX_ACCEL=y the scrolling speed
> > comes back (only a bit slower than with 2.6.8.1 without
> > CONFIG_FB_3DFX_ACCEL):
> >
> > $ time cat MAINTAINERS: ~2.67s
>
> Ok.  However, I'm still wondering at the scrolling speed, it's a bit
> slower than what I would expect (I get < 1 second with vesafb which is
> completely unaccelerated).
>
> Did you set info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN?
yes

> Do you use the 'nopan' boot option?
no

>
> Because if you answer yes to the first question and no to the second,
> that means that tdfxfb_pan_display() is probably broken.
>
> BTW, what does fbset -i say, and what's your hardware setup?

ASUS A7V (VIA Apollo KT133 Chipset)
AMD Duron 750
3dfx Voodoo Banshee 16 MB

lspci -v (attached)

$ fbset -i:	(from 2.6.9-rc1 + your new patch without CONFIG_FB_3DFX_ACCEL: 
see the next e-mail)

mode "800x600-85"
    # D: 60.753 MHz, H: 55.839 kHz, V: 84.992 Hz
    geometry 800 600 800 20971 8
    timings 16460 160 64 36 16 64 5
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : 3Dfx Banshee
    Address     : 0xe4000000
    Size        : 16777216
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 0
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 800
    MMIO Address: 0xe0000000
    MMIO Size   : 33554432
    Accelerator : Unknown (31)


>
> > Another interesting thing is that if I enable CONFIG_FB_3DFX_ACCEL
> > without your patch the screen becomes black and the kernel stop working
> > at boot time (when the mode switch happens).
>
> tdfxfb_cursor() is broken, so I disabled that.  It's the reason your
> machine hangs at boot time if CONFIG_FB_3DFX_ACCEL is set to y.

ok

>
> Tony

-- 
	Paolo Ornati
	Gentoo Linux (kernel 2.6.9-rc1)

[-- Attachment #2: lspci.gz --]
[-- Type: application/x-gzip, Size: 1023 bytes --]

Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower

[David S. Miller]

On Tue, 31 Aug 2004 21:33:40 +0200
Paolo Ornati <ornati@fastwebnet.it> wrote:

> The recent changes in frame buffer code seems to affect performance of 
> scrolling on my system:
 ...
> CONFIG_FB=y
> CONFIG_FB_3DFX=y
> # CONFIG_FB_3DFX_ACCEL is not set

Maybe try turning on 3DFX_ACCEL?