Re: [Linux-fbdev-devel] Text console scrolling

[Krzysztof H. <krz...@wp...>]

On Thu, 19 Jul 2007 00:08:56 +0800
"Antonino A. Daplas" <ad...@gm...> wrote:

> On Wed, 2007-07-18 at 17:10 +0200, Geert Uytterhoeven wrote:
> > 	Hi all,
> > 
> > Yesterday, FBINFO_READS_FAST was faster in some cases, but much slower in
> > others, so I didn't really know whether I should enable it or not.
> > 
> > Today, FBINFO_READS_FAST is faster in all test cases, so the choice is clear.
> > 
> 
> The improvement of scroll_move is courtesy of Ondrej's smart blitter
> patch.
[...]
>  
> > Note that there are still a few cases where today's fastest option is a bit
> > slower than yesterday's fastest option.
> > 
> 
> All things equal, the speed of the smart blitter will depend on:
> 
> The less different the contents, the more the smart blitter will speed
> up (because less characters are actually moved). If the contents are
> totally different, then the blitter spends as much time as the old
> (dumb) blitter plus the time spent on the compare. 
> 

My guess is that comparing is relatively fast comparing to preparation of the blit operation.  
One of the very first versions of the patch had a variant to merge small blits into bigger ones.
It was done by regarding the first character after difference (string of different character) as different too.
An advantage was fewer blitter operations but the operations got bigger at least by one character.

You may look here (see MERGE_BLITS define):

http://marc.info/?l=linux-fbdev-devel&m=117869435713671&w=2

Some tests result on cards with real blitter:

http://marc.info/?l=linux-fbdev-devel&m=117881573823606&w=2

As you see, merging blits gave speed up on some cards (comparing to current method) despite it had more to compare.
But it was usually lost at higher bpp as amount of data to move grown faster.

I am interested in results of scrolling speeds with merged blits on your hardware.

Regards,
Krzysztof