Crusher wrote:
Set : 4910289 pix/sec 9590.40 K/sec Zero : 3235813 pix/sec 6319.94 K/sec Copy : 4551111 pix/sec 8888.88 K/sec Conv : 4542698 pix/sec 8872.45 K/sec Conversion attained 99.81% copy speed
...and you are talking about what? :-? :-)
The pixeltest program was originally designed to benchmark some graphics conversion routines I created compared to simple copy/clear/set, all of which can operate direct to VRAM and hence are limitied by the bus speed.
1) Set
The set test uses an 16x unrolled loop of
move.l d0, (a0)+
where d0 contains the value to write (which can be more than one pixel, but always 32-bit value)
This particular test is completely limited by the bus
2) Zero
The zero test uses a 16x unrolled loop of
clr.l (a0)+
which zeros the address. This was purely to see how clr.l (a0)+ would compare to move.l (a0)+ over different busses. So far, and unsurprsingly, the move.l is faster.
3) Copy
The copy test simply involves copying data from system ram to VRAM, using a 16x unrolled loop of
move.l (a1)+, (a0)+
It doesn't actually do any modulus compensation or anything (which is why the test can look odd on some window sizes), but it is designed to test how fast a realistic memory -> vram transfer takes.
4) Conversion
The conversion actually tests some conversion code I wrote. This code converts a rectangular block of pixels (complete with modulus) from the source (in system ram) to a rectangular block of pixels in VRAM, taking care of modulus.
There is actually a bug (not dangerous) in that conversion code, that doesnt update the row address properly for certian modulus values (from window widths that arent a multiple of 32), but its irrelavent to the bus speed estimation argument anyway. For the sizes chosen in the test, that bug is never encountered anyway.
The way the pixeltest program is invoked for this particular test, this conversion is basically a copy operation, since the source and destination formats are the same in both cases. The fact it isnt as fast as the copy test (3) is that it has to do row by row conversion and take care of modulus.
For the purposes of pure bus speed (no burstmode) estimation, the only value you need to look at is the set test.
Read on only if you are interested...
The pixeltest program is built upon my C++ portability framework and is designed to test some low level pixel conversion code provided by the platform specific back end. This is software on most systems (including amiga). Pixel formats vary from system to system, so my backend needs to be able to convert from whatever format the programmer is using to whatever format the system prefers for a given representation.
Normally, as a library user you'd just use either 8/15/16/24/32 bits (a)rgb, without caring about endian ness or rgb mapping. At the end of the day, if you write a block of pixels (usually stored in an ImageBuffer object) to a Surface object, the absolute conversion is performed for you. Imagine it works a bit like this:
ImageBuffer*myImage = ImageLoader::loadNew("test/image.ppm");
/*
We don't need to know what actual pixel format the image is, nor the surface.
We can enquire, or we could have used eg:
ImageLoader::loadNewImage(char* name, Pixel::Type format);
to enforce a given format.
*/
Surface* mySurface = myDisplay->getDrawSurface();
mySurface->putImageBuffer(myImage, xpos, ypos);
Things like pixel conversion are hidden from you, as is clipping in this case.
However, you can select 'absolute' formats, such as 'rgb16b', meaning 16-bits rgb (5:6:5), big endian representation, if you know what (ans why) you are doing.
Anyway, the pixeltest program is designed to test these 'invisible' conversion routines, so if you want to see the conversion code operate (and bug free :-) ), you need to run the program from a shell as follows
pixeltest width
height fmt
where
is a multiple of 32, eg 320, 512, 640, 800 (minimum is 160, default is 160 IIRC)
is the height. Any value is OK (minimum is 120, default is 240)
is the source format. Should be one of the following absolute formats:
rgb15b
rgb15l
bgr15b
bgr15l
rgb16b
rgb16l
bgr16b
bgr16l
rgb24p
bgr24p
argb32b
argb32l ( aka brga )
abgr32b
abgr32l ( aka rgba )
In the above, the last letter indicates endian format, eg b = big, l = little. The 24-bit sources use 'p' indicating 3-byte packed.
The destination format is whatever format your workbench screen is using. You don't really have much say in that other than what your screenmode prefs lets you set. Note that 8 bit screen depths are not supported by this program.
When you invoke the program you will see some output such as (this for a argb32b source running on a 16-bit rgb desktop)
Test data pixel format
Bytes : 4, endian native
Bits : A[ 8] R[ 8] G[ 8] B[ 8]
Offsets : A[ 24] R[ 16] G[ 8] B[ 0]
Maxima : A[255] R[255] G[255] B[255]
Window pixel format
Bytes : 2, endian native
Bits : A[ 0] R[ 5] G[ 6] B[ 5]
Offsets : A[ 0] R[ 11] G[ 5] B[ 0]
Maxima : A[ 0] R[ 31] G[ 63] B[ 31]
Now, what you are seeing is a breakdown of source and destination formats:
Endian : native / swapped
Bits : number of bits for each channel
Offsets : offsets of bits within word
Maxima : maximum integer value for channel
