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)
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
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;
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)
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)
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
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
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)
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)
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
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)
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