From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: Paolo Ornati <ornati@fastwebnet.it>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.9-rc1: scrolling with tdfxfb 5 times slower
Date: Thu, 2 Sep 2004 20:20:18 +0800 [thread overview]
Message-ID: <200409022020.19062.adaplas@hotpop.com> (raw)
In-Reply-To: <200409021123.26299.ornati@fastwebnet.it>
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
next prev parent reply other threads:[~2004-09-02 12:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-31 19:33 2.6.9-rc1: scrolling with tdfxfb 5 times slower Paolo Ornati
2004-08-31 20:28 ` Antonino A. Daplas
2004-09-01 7:10 ` Paolo Ornati
2004-08-31 23:29 ` Antonino A. Daplas
2004-09-01 7:20 ` Paolo Ornati
2004-09-01 10:21 ` Antonino A. Daplas
2004-09-01 10:51 ` Antonino A. Daplas
2004-09-01 11:55 ` Paolo Ornati
2004-09-01 20:10 ` Antonino A. Daplas
2004-09-02 9:23 ` Paolo Ornati
2004-09-02 12:20 ` Antonino A. Daplas [this message]
2004-09-02 17:10 ` Paolo Ornati
2004-09-02 19:52 ` Antonino A. Daplas
2004-09-01 20:20 ` Antonino A. Daplas
2004-09-02 9:26 ` Paolo Ornati
2004-09-01 11:48 ` Paolo Ornati
2004-09-01 1:21 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200409022020.19062.adaplas@hotpop.com \
--to=adaplas@hotpop.com \
--cc=adaplas@pol.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ornati@fastwebnet.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox