Blitter speed tests (was: smart blitter usage for scrolling)

Krzysztof Helt

author

2007-05-10 16:48 UTC #0 lore raw

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/

Antonino A. Daplas

2007-05-10 20:24 UTC #1 lore raw

Quoted 24 lines · Krzysztof Helt

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.

Quoted 6 lines

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/

Antonino A. Daplas

2007-05-10 20:36 UTC #2 lore raw

Quoted 6 lines · Antonino A. Daplas

Quoted 2 lines · Krzysztof Helt
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/

Antonino A. Daplas

2007-05-10 20:31 UTC #3 lore raw

In reply to Krzysztof Helt

Quoted 18 lines · Krzysztof Helt

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().

Quoted 5 lines

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/

Krzysztof Helt

author

2007-05-11 06:00 UTC #4 lore raw

Re: Blitter speed tests (was: smart blitterusage for scr olling)

In reply to Krzysztof Helt

Dnia 10-05-2007 o godz. 22:36 Antonino A. Daplas napisa³(a):

Quoted 5 lines · Antonino A. Daplas

Quoted 3 lines
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 3 lines

method.
SCROLL_MOVE is faster at lower bit depths because the bitmap

preparation

Quoted 1 line

for the putcs method slows down SCROLL_REDRAW. But as the bit

depth

Quoted 1 line

goes up, the amount of data moved by bmove goes up but at a

higher rate

Quoted 1 line

than the data moved by putcs. Thus SCROLL_MOVE loses its edge

at 16-32

Quoted 4 lines

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/

Antonino A. Daplas

2007-05-11 12:15 UTC #5 lore raw

Re: Blitter speed tests (was: smart blitterusage for scr olling)

Quoted 16 lines · Krzysztof Helt

Dnia 10-05-2007 o godz. 22:36 Antonino A. Daplas napisaÅ‚(a):
Quoted 5 lines · Antonino A. Daplas
Quoted 3 lines
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 3 lines
method.
SCROLL_MOVE is faster at lower bit depths because the bitmap
preparation
Quoted 1 line
for the putcs method slows down SCROLL_REDRAW. But as the bit
depth
Quoted 1 line
goes up, the amount of data moved by bmove goes up but at a
higher rate
Quoted 1 line
than the data moved by putcs. Thus SCROLL_MOVE loses its edge

Quoted 8 lines

at 16-32
Quoted 4 lines
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.

Quoted 5 lines

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel