From: "Antonino A. Daplas" <adaplas@gmail.com>
To: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: linux-fbdev-devel <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Blitter speed tests (was: smart blitterusage for scr olling)
Date: Fri, 11 May 2007 20:15:25 +0800 [thread overview]
Message-ID: <1178885725.4887.9.camel@daplas> (raw)
In-Reply-To: <46440680635cb@wp.pl>
On Fri, 2007-05-11 at 08:00 +0200, Krzysztof Helt wrote:
> Dnia 10-05-2007 o godz. 22:36 Antonino A. Daplas napisał(a):
> > On Fri, 2007-05-11 at 04:24 +0800, Antonino A. Daplas wrote:
> > > If you do, it might even be wise to change the default from
> > > SCROLL_REDRAW to SCROLL_MOVE...?
> > >
> > Come to think of it we'll probably just let the driver choose
> the scroll
> > method.
> >
> > SCROLL_MOVE is faster at lower bit depths because the bitmap
> preparation
> > for the putcs method slows down SCROLL_REDRAW. But as the bit
> depth
> > goes up, the amount of data moved by bmove goes up but at a
> higher rate
> > than the data moved by putcs. Thus SCROLL_MOVE loses its edge
> at 16-32
> > bpp. At what point these lines intersect we really don't know as it
> > depends on the hardware and the driver's imageblit/copyarea
> > implementation.
> >
>
> If you want really complicated solution one can switch
> FB_READS_FAST flag depending on the bit depth inside each driver ;-)
I was actually thinking of that, but I'm not considering it anymore.
It's too complicated and there are too many unknowns.
>
> I think that a simple solution is to leave everything untouched
> except tdfxfb and nvidiafb drivers. These two should add
> FB_READS_FAST flag permanently to use blitter for scrolling.
>
Yes, I benchmarked this with a Geforce4 MX 4000. Your scroll method
beats scroll_redraw in all cases (all supported resolutions and bit
depths) and the only time the old SCROLL_MOVE was faster is at 640x480
at 8bpp by only a few percent. At other resolutions and depths, your
scrolling method wins hands down (by a lot).
This is a good patch. Thanks.
Tony
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
next prev parent reply other threads:[~2007-05-11 12:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-10 16:48 Blitter speed tests (was: smart blitter usage for scrolling) Krzysztof Helt
2007-05-10 20:24 ` Antonino A. Daplas
2007-05-10 20:36 ` Antonino A. Daplas
2007-05-11 6:00 ` Blitter speed tests (was: smart blitterusage for scr olling) Krzysztof Helt
2007-05-11 12:15 ` Antonino A. Daplas [this message]
2007-05-10 20:31 ` Blitter speed tests (was: smart blitter usage for scrolling) Antonino A. Daplas
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=1178885725.4887.9.camel@daplas \
--to=adaplas@gmail.com \
--cc=krzysztof.h1@wp.pl \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.