From: Krzysztof Helt <hidden> Date: 2007-05-10 16:48:36
Hi,
Below are tests of different scrolling methods for cards I have.
All tested drivers use SCROLL_REDRAW method. I forced SCROLL_MOVE
method by adding flag FB_READS_FAST.
Here are some conclusions:
Comparing two new methods: smart blitting and smart blitting with
merge, the merge of blits gives some speed up at lower bit
depths, but it is usually lost at higher ones. So we can choose
both ways (with or without the merge).
The smart blitting is so much faster in many cases comparing to
the current dump SCROLL_MOVE, that it can replace the current
method. For some cards it is even faster than SCROLL_REDRAW with
accelerated fb_imageblit().
The drivers tdfxfb and nvidiafb will benefit from switching to
SCROLL_MOVE method if the smart blitting is added (the tdfxfb
even without it). I wonder if Geforce cards also shows this speed
up if switched to the SCROLL_MOVE method but I have no card to
test.
The mach64 case is strange: it gives upper hand to smart blitting
but not at 32-bit depth.
I will prepare a patch with drop-in replacement for current
SCROLL_MOVE method without blits merging (it is the cleanest
solution).
Regards,
Krzysztof
Test results:
test machine: dual Pentium 3 866MHz, 512 MB RDRAM, AGP 4x
The columns contains results for different depths and resolutions
(in this order):
1024x768-75 depth 8
1024x768-75 depth 16
1024x768-75 depth 32
1600x1200-60 depth 8
*for 2MB cards it was 1024x512-75 depth 32 instead of 1024x768-75
Permedia 2 AGP (Fire GL 1000 Pro 8MB)
redraw 3.611 --.---- 15.290 6.258
smart move 3,700 6.317 9.829 6.553
smart merge 3.952 6.731 10.504 6.968
move 11.428 --.---- 29.527 31.258
Permedia 2V PCI (EONtronic/3dlabs reference board 8MB)
redraw 2.631 --.---- 7.411 4.364
smart move 2.375 --.---- 4.846 3.986
smart merge --.---- --.---- --.---- --.----
move 4.025 --.---- 13.895 18.881
ATI Mach64 PCI (recognized as mach64 GU 4MB EDO)
redraw 2.460 2.456 3.403 3.891
smart move 0.930 1.703 5.904 1.717
smart merge 0.820 1.656 6.102 1.552
move 1.757 4.073 16.010 5.084
MGA 2064W PCI (Millenium I 2MB*)
redraw 0.565 0.792 0.918 0.972
smart move 0.894 1.469 1.930 1.505
smart merge 0.828 1.454 2.007 1.429
move 1.743 3.600 5.390 3.858
MGA 1064SG PCI (Mystique I 2MB*)
redraw 0.621 0.981 1.440 1.121
smart move 1.170 2.040 3.367 2.052
smart merge 1.052 2.000 3.519 1.887
move 2.056 4.747 9.461 5.418
MGA G200 AGP (Milenium G200 8MB SDRAM)
redraw 0.480 0.632 1.271 0.800
smart move 0.438 0.750 1.751 0.813
smart merge 0.393 0.700 1.770 0.758
move 0.692 1.524 3.837 1.738
TNT 16MB AGP (16MB SDRAM)
redraw 1.992 1.708 2.116 2.475
smart move 0.271 0.644 0.736 1.905
smart merge 0.252 0.261 1.990 0.657
move 0.493 1.736 4.793 2.080
Savage4 8MB AGP (Number Nine SR9)
redraw 0.382 0.429 0.926 0.637
smart move 0.356 0.892 1.990 0.642
smart merge 0.371 0.948 2.124 0.689
move 1.036 2.675 5.729 2.914
Voodoo3 16MB PCI (2000 version)
redraw 0.611 0.615 0.621 0.998
smart move 0.143 0.240 0.524 0.256
smart merge 0.134 0.249 0.555 0.242
move 0.292 0.640 1.528 0.772
----------------------------------------------------
Juwenalia Krakowskie 2007. Hey, Coma, Myslovitz,
Vavamuffin. Kabaretony i wielki korowód
7-13 maja Klub ¯aczek, Studio, Rotunda i Stadion Wis³y
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fjuwenaliakrakow.html&sid=1136
-------------------------------------------------------------------------
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/
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-05-10 20:24:42
On Thu, 2007-05-10 at 18:48 +0200, Krzysztof Helt wrote:
Hi,
Below are tests of different scrolling methods for cards I have.
All tested drivers use SCROLL_REDRAW method. I forced SCROLL_MOVE
method by adding flag FB_READS_FAST.
Here are some conclusions:
Comparing two new methods: smart blitting and smart blitting with
merge, the merge of blits gives some speed up at lower bit
depths, but it is usually lost at higher ones. So we can choose
both ways (with or without the merge).
The smart blitting is so much faster in many cases comparing to
the current dump SCROLL_MOVE, that it can replace the current
method. For some cards it is even faster than SCROLL_REDRAW with
accelerated fb_imageblit().
The drivers tdfxfb and nvidiafb will benefit from switching to
SCROLL_MOVE method if the smart blitting is added (the tdfxfb
even without it). I wonder if Geforce cards also shows this speed
up if switched to the SCROLL_MOVE method but I have no card to
test.
The mach64 case is strange: it gives upper hand to smart blitting
but not at 32-bit depth.
I will prepare a patch with drop-in replacement for current
SCROLL_MOVE method without blits merging (it is the cleanest
solution).
Nice benchmarks and results!
The test is done on cards with both accelerated imageblit and copyarea.
Do you get the same results in unaccelerated drivers (vesafb)?
If you do, it might even be wise to change the default from
SCROLL_REDRAW to SCROLL_MOVE...?
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/
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-05-10 20:31:40
On Thu, 2007-05-10 at 18:48 +0200, Krzysztof Helt wrote:
Hi,
Below are tests of different scrolling methods for cards I have.
All tested drivers use SCROLL_REDRAW method. I forced SCROLL_MOVE
method by adding flag FB_READS_FAST.
Here are some conclusions:
Comparing two new methods: smart blitting and smart blitting with
merge, the merge of blits gives some speed up at lower bit
depths, but it is usually lost at higher ones. So we can choose
both ways (with or without the merge).
The smart blitting is so much faster in many cases comparing to
the current dump SCROLL_MOVE, that it can replace the current
method. For some cards it is even faster than SCROLL_REDRAW with
accelerated fb_imageblit().
The drivers tdfxfb and nvidiafb will benefit from switching to
SCROLL_MOVE method if the smart blitting is added (the tdfxfb
even without it). I wonder if Geforce cards also shows this speed
up if switched to the SCROLL_MOVE method but I have no card to
test.
I'll do the test for nvidia cards.
-------------------------------------------------------------------------
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/
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-05-10 20:36:36
On Fri, 2007-05-11 at 04:24 +0800, Antonino A. Daplas wrote:
On Thu, 2007-05-10 at 18:48 +0200, Krzysztof Helt wrote:
quoted
Hi,
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.
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/
From: Krzysztof Helt <hidden> Date: 2007-05-11 06:00:43
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:
quoted
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 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.
Take into account that the faster machine may speed up the redraw
operation, because it is faster, while blitting will have the
same speed.
On the other hand, most cards I have cannot even closely compare
their on-board memory bandwidth to the one on newer cards like
Geforce or Radeon (so blitting should be much faster on the newer
cards). The blitting merge can help these cards (no hardware to
tests).
Regards,
Krzysztof
----------------------------------------------------
Wczoraj chodzi³o o honor. Dzisiaj - o sprawiedliwo¶æ.
Mark Wahlberg i Danny Glover w pe³nym akcji filmie
"STRZELEC" - w kinach od 11 maja.
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fstrzelec.html&sid=1134
-------------------------------------------------------------------------
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/
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-05-11 12:15:39
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):
quoted
On Fri, 2007-05-11 at 04:24 +0800, Antonino A. Daplas wrote:
quoted
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
quoted
method.
SCROLL_MOVE is faster at lower bit depths because the bitmap
preparation
quoted
for the putcs method slows down SCROLL_REDRAW. But as the bit
depth
quoted
goes up, the amount of data moved by bmove goes up but at a
higher rate
quoted
than the data moved by putcs. Thus SCROLL_MOVE loses its edge
at 16-32
quoted
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