Computer Science
accel(6) Svgalib User Manual accel(6)
NAME
accel - tests the new style svgalib accelerator interface
SYNOPSIS
accel
DESCRIPTION
Test new-style accelerated functions (As of this writing:
Ark, Cirrus, Chips & Technologies cards, and Mach32 only).
For other cards the demo will not work (well it will com-
plain about missing accelerator support). Don't worry
about this.
During the development of the Mach32 new style driver for
1.2.12, this demo was massively extended to check the
Mach32 functions.
Upon startup it lists all supported SVGA modes and asks
you to enter a number identifying the mode to be tested.
The supported subfunctions of vga_accel(3) in this mode
are listed and the demo instructs to press <Return> to
start the demos.
If supported, all drawing operations are performed in the
background.
Then the following tests are performed:
Positioning tests
These tests were originally intended to check that the
accelerator commands work on the proper screen locations.
The screen shows 12 (4 x 3) smaller areas with red crosses
in the corners. When everything is ok, the drawings should
reach right in the corners of the crosses.
A given card may not support all operations listed here.
In that case the resp. test area just shows the red
crosses. For tests performed, the name of the test is
printed below the area. The tests are (from left to right,
top to bottom):
1. A green box is drawn with vga_accel(ACCEL_FILLBOX).
2. A cross of green lines is drawn with
vga_accel(ACCEL_DRAWLINE).
3. A linux pixmap just fitting into the crosses is
drawn with vga_accel(ACCEL_PUTIMAGE).
4. A pixmap just fitting into the crosses is drawn
into the red crosses (by vgagl(5) which may or may
not use the accelerator). The pixmap is then copied
to a few lines/columns below. Green crosses mark
the intended destination position.
5. Works like 3. but copies to an area above the ori-
gin. The accelerator must ensure that the overlap-
ping areas are handled non corrupting. Thus, watch
that the copy operation is properly performed.
6. A green triangle is drawn above the top/left to
bottom/right diagonal by use of
vga_accel(ACCEL_DRAWHLINELIST).
7. Certain bitmaps are copied to the screen. In the
corners you'll see the digits
0 top/left, green on red.
1 top/right, red on green.
2 bottom/left, black on white.
3 bottom/right, white on black. Note that some
black border, not the digit will be aligned
to the red crosses.
Finally, a yellow wizard image is drawn into the
center.
The bit ordering for bitmaps is a bit weird. Please
check that the digits are not mirrored or flipped.
8. This time bitmap transparency is tested by drawing
wizard images onto the aforementioned linux pixmap
(left to right, top to bottom) in yellow, red,
green, and cyan. The background of the yellow wiz-
ard is masked out by a black border bitmap. Note
that the wizard will not reach into the red corners
because the bitmap has some (transparent) border.
9. The text below this box is copied as a monochrome
bitmap from the screen into the corners listed
under 7. in the same colors.
10. Two green rectangles with an edge cut out from the
bottom is drawn using vga_accel(ACCEL_POLY-
LINE).Thereisanintendedbugwhichdrawsthecenterofthe
top line twice. If supported, the lower rectangle
is drawn in cyan and with the xor raster operation
s.t. the buggy point is not drawn thus leaving a
pin hole.
11. vga_accel(ACCEL_POLYHLINE)isusedtodrawsomegreen-
lineswhichmakesthisarealook like a green box with a
cut out, black M-style shape.
12. A weird green polygon is filled in red with
vga_accel(ACCEL_POLYFILLMODE) using the techniques
given in vga_accel(3). This needs some offscreen
memory. If VGA memory is tight in that resolution
the test cannot be performed.
After this screen, you'll have to hit <Return> to con-
tinue.
Raster operations
Again, red cross bordered areas are drawn on the screen,
this time for each of the supported raster operations. For
ROP_AND and ROP_XOR the areas are filled in white first.
Three overlapping boxes A, B, C are drawn such that you
see the following areas.
AAAAAAddddBBBBBB
AAAAAAddddBBBBBB
AAAAAAddddBBBBBB
AAAAeeggggffBBBB
AAAAeeggggffBBBB
AAAAeeggggffBBBB
CCCCCCCC
CCCCCCCC
CCCCCCCC
The pictures should show:
1. Replace mode. A, B, C are red, green, blue. They
just overlap, yielding d - green and e, f, g -
blue.
2. The colors mix using ROP_OR (and a nice color
table). The overlapping areas become the additive
color mix: d - yellow, e - magenta, f - cyan, and g
- white.
3. ROP_AND is used. The background is filled white
first, s.t. there is something in video memory to
and with non trivially. We have A, B, C in cyan,
magenta, yellow and d, e, f, g in blue, green, red,
black.
4. ROP_XOR is used and the background filled white
first too. A, B, C are red, green, blue again, but
the overlapping areas d, e, f, g become blue,
green, red, white.
5. ROP_INV is used, s.t. A, B, C are all white and d,
e, f, g become black, black, black, white. Note
that this is not done by using ROP_XOR and drawing
A, B, C in white. Instead A, B, C are drawn in the
usual
red, green, blue. However, the accelerator just
inverts the memory contens.
If the accelerator supports raster operations for
ACCEL_DRAWHLINELIST actually disks (well, ellipses) are
drawn instead of boxes.
After this screen, you'll have to hit <Return> to con-
tinue.
Replace QuixDemo
If ACCEL_DRAWLINE is supported, a Quix like bouncing
series of lines in varying colors is drawn. The lines are
removed from the screen by overdrawing them in black, thus
erasing the dots and text on the background.
The test lasts about 5 seconds and some statistics are
printed to stdout.
XOR Mode QuixDemo
As before, but this time all lines are drawn in ROP_XOR
mode (if ACCEL_DRAWLINE supports raster operations). Thus
the background will not be destroyed this time.
The test lasts about 5 seconds and some statistics are
printed to stdout.
FillBox Demo
The screen is ACCEL_FILLBOX filled with a series of boxes
of increasing colors. In truei/high color modes you'll
probably only see a series of varying blue tones (because
these are at the beginning of the color table and there
are soo many of them).
The test lasts about 5 seconds and some statistics are
printed to stdout.
ScreenCopy Demo
Some random dots are drawn on the screen and thirds of the
screen contents are moved around using ACCEL_SCREENCOPY.
The test lasts about 5 seconds and some statistics are
printed to stdout.
Scroll Demo
Some random dots are drawn on the screen and moved one
line up with ACCEL_SCREENCOPY. In offscreen memory a new
line is prepared which will be cleared by ACCEL_FILL-
BOXandmoveinfrombelow.Thistestrequiressomeoffscreenand-
willnot be performed if video memory is very tight.
The test lasts about 5 seconds and some statistics are
printed to stdout.
FillBox with DrawHLineList Demo
Like the FillBox test, but no box fill is done but the
screen is filled with a list of horizontal lines drawn
with ACCEL_DRAWHLINELIST.
The test lasts about 5 seconds and some statistics are
printed to stdout.
FillBox XOR Mode Demo
Like the FillBox test, but the XOR raster operation is
used.
The test lasts about 5 seconds and some statistics are
printed to stdout.
PutBitmap Demo
The screen is filled with bitmasks consisting of tiny ver-
tical lines alternating in red and blue.
The test lasts about 5 seconds and some statistics are
printed to stdout.
SOME DATAPOINTS
Here is a list of speed listings for some cards. Please
keep in mind that also the calling overhead for the pro-
gram is measured. This seems to be esp. true for the
QuixDemo.
Results on a Cirrus GD5434-E with 2Mb:
640x480x256 60 Hz
FillBox: 200.3 Mpixels/s (200.3 Mbytes/s)
ScreenCopy: 51.0 Mpixels/s (51.0 Mbytes/s)
Scroll Demo: 50.5 Mpixels/s (50.5 Mbytes/s)
FillBox XOR: 83.2 Mpixels/s (83.2 Mbytes/s)
320x200x256 70 Hz
FillBox: 200.1 Mpixels/s (200.1 Mbytes/s)
ScreenCopy: 52.3 Mpixels/s (52.3 Mbytes/s)
Scroll Demo: 51.2 Mpixels/s (51.2 Mbytes/s)
FillBox XOR: 87.1 Mpixels/s (87.1 Mbytes/s)
640x480x32K 60 Hz
FillBox: 90.9 Mpixels/s (181.8 Mbytes/s)
ScreenCopy: 23.1 Mpixels/s (46.3 Mbytes/s)
Scroll Demo: 23.0 Mpixels/s (46.1 Mbytes/s)
FillBox XOR: 37.2 Mpixels/s (74.5 Mbytes/s)
640x480x16M (32-bit) 60 Hz
FillBox: 35.5 Mpixels/s (142.3 Mbytes/s)
ScreenCopy: 9.3 Mpixels/s (37.3 Mbytes/s)
Scroll Demo: 9.2 Mpixels/s (37.1 Mbytes/s)
FillBox XOR: 14.6 Mpixels/s (58.6 Mbytes/s)
On a Cirrus Logic 5426 VLB (50 MHz MCLK):
640x480x256 60 Hz
FillBox: 32.8 Mpixels/s (32.8 Mbytes/s)
ScreenCopy: 16.4 Mpixels/s (16.4 Mbytes/s)
Scroll Demo: 16.3 Mpixels/s (16.3 Mbytes/s)
FillBox XOR: 16.5 Mpixels/s (16.5 Mbytes/s)
640x480x32K 60 Hz
FillBox: 12.2 Mpixels/s (24.4 Mbytes/s)
ScreenCopy: 6.1 Mpixels/s (12.2 Mbytes/s)
Scroll Demo: 6.0 Mpixels/s (12.1 Mbytes/s)
FillBox XOR: 6.1 Mpixels/s (12.2 Mbytes/s)
Tweaked to 60 MHz MCLK:
640x480x256 60 Hz
FillBox: 42.1 Mpixels/s (42.1 Mbytes/s)
ScreenCopy: 21.0 Mpixels/s (21.0 Mbytes/s)
Scroll Demo: 20.9 Mpixels/s (20.9 Mbytes/s)
FillBox XOR: 21.1 Mpixels/s (21.1 Mbytes/s)
640x480x32K 60 Hz
FillBox: 16.7 Mpixels/s (33.5 Mbytes/s)
ScreenCopy: 8.3 Mpixels/s (16.7 Mbytes/s)
Scroll Demo: 8.3 Mpixels/s (16.7 Mbytes/s)
FillBox XOR: 8.3 Mpixels/s (16.7 Mbytes/s)
Results on a Mach32 EISA with 2Mb VRAM:
1280x1024x256 60 Hz
Replace QuixDemo: 12.1 Klines/s (6.7 Mpixels/s or
6.7 Mbytes/s)
Xor QuixDemo: 9.9 Klines/s (5.1 Mpixels/s or 5.1
Mbytes/s)
FillBox: 75.4 Mpixels/s (75.4 Mbytes/s)
ScreenCopy: 26.4 Mpixels/s (26.4 Mbytes/s)
Scroll Demo: 28.7 Mpixels/s (28.7 Mbytes/s)
FillBox with DrawHlineList: 73.1 Mpixels/s (73.1
Mbytes/s)
FillBox XOR: 37.9 Mpixels/s (37.9 Mbytes/s)
PutBitmap: 15.6 Mpixels/s (15.6 Mbytes/s)
1024x768x64K 72Hz
Replace QuixDemo: 12.3 Klines/s (5.2 Mpixels/s or
10.5 Mbytes/s)
Xor QuixDemo: 9.0 Klines/s (5.1 Mpixels/s or 10.3
Mbytes/s)
FillBox: 37.6 Mpixels/s (75.2 Mbytes/s)
ScreenCopy: 13.2 Mpixels/s (26.4 Mbytes/s)
Scroll Demo: 13.2 Mpixels/s (26.4 Mbytes/s)
FillBox with DrawHlineList: 37.0 Mpixels/s (74.0
Mbytes/s)
FillBox XOR: 18.9 Mpixels/s (37.8 Mbytes/s)
PutBitmap: 15.2 Mpixels/s (30.5 Mbytes/s)
You're encouraged to send in more data. This demo is part
of svgalib and can be found in the demos/ subdirectory of
the original svgalib distribution. However, it is not
installed in the system by default, s.t. it is unclear
where you can find it if your svgalib was installed by
some linux distribution. Even then, when you have the demo
on your system, you probably won't have the sources s.t.
it is only of limited use for you.
In case of any such problem, simply get an svgalib distri-
bution from the net. You even don't need to install it.
Just make in the demos/ subdirecty. As of this writing,
svgalib-1.2.12.tar.gz is the latest version and can be
retrieved by ftp from sunsite.unc.edu at
/pub/Linux/libs/graphics and tsx-11.mit.edu at
/pub/linux/sources/libs which will most probably be mir-
rored by a site close to you.
SEE ALSO
svgalib(7), vgagl(7), libvga(5), vga_accel(3),
threed(6), bg_test(6), eventtest(6), forktest(6), fun(6),
keytest(6), mousetest(6), scrolltest(6), speedtest(6),
spin(6), testaccel(6), testgl(6), testlinear(6), vgat-
est(6), plane(6), wrapdemo(6)
AUTHOR
This manual page was edited by Michael Weller <eowmob@exp-
math.uni-essen.de>. The demo and most of its documentation
is due to Harm Hanemaayer <H.Hanemaayer@inter.nl.net>.
Svgalib (>= 1.2.11) 29 July 1997 1
Back to the index