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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/