Date:	Mon, 6 Sep 93 16:14:50 CST
From:	michaels AT vsl DOT com DOT AU (Michael Snoswell)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Fastest VLB graphics card for writing pixels

I'm writing a networked VR app that needs fast graphics. I've just changed the
rendering engine to use zbuffer scanline stuff instead of flat polys using
the LIBGRX polyfill routine. I'm just using flat colour for the moment but
it still runs about 5 times slower than the LIBGRX polygon scanline routine.
(For those interested, I'm using the Graphics Gems poly_scan.c code)

I have a 486/33 VLB but with an ISA ET4000 card. At 800x600x256 I used to get
about 7-8 fps, now with zbuffer stuff I get 1-2fps :-(

I have been told by numerous sources who know better than I that the 
poly_scan.c code is about as optimised at you can get. Given that it's not 
doing a whole lot more than a 2d polygon scanline routine (remember, I'm using
flat colour, no Gouraud shading, yet!) the difference must be in the zbuffer
check and the putpixel call (the LIBGRX version). (Well, the poly scan in 
LIBGRX uses a stos to fill a line at a time. how much slower would a pixel by
pixel fill be on a machine cycle ratio? I have no idea about assem stuff)

STOP PRESS! Eat my words. The SetPixel function is a dog, I just traced it
through LIBGRX, gads, there's a huge overhead...

Well my original question was going to be about VGA cards. As I have some VLB
slots I'm not using here. I know accelerated cards with things like S3 chips 
don't implicitly speed up writing individual pixels and the video test results
that have been floating around give one pause to think. I know that if you
have VRAM you can write indivual pixels faster (and more so using VLB). I have 
the list of VGA card timings but the compiled version DJ posted omitted the
wait state data (saving bandwidth I guess :-) 

Anyway, follow my reasoning and see if you can help me.

According to that list a 486/33 with ET4000 ISA gave 2,285 at 8 bits (s-v 
column, 6th row) whcih is what I have now.

I assume that's 1000 transfers per second units (I didn't keep the original
posting so I'm not sure here). At 33 MHz that gives 33/2.285 = 14.4 wait states
right? Now there weren't any 486/33 VLB machines there, but of the DX266 ones,
the ET4000LB looks best (Dell has a slightly different bus or something that I
haven't got?). But considering I'm using LIBGRX it's be nice to access those
hardware polygons and line drawing routines for other things as there is a
Stealth S3 driver (but not well supported according to some comments in the
LIBGRX source, libgrx.h, line 368). Now I assume here that the LIBGRX driver 
for the Stealth uses the hardware polygons and line routines, am I right? Then
I should get a Stealth VLB card.

What sort of 8-bit s->v could I expect on my machine using a this? And back
to the original reason: How will this new setup (using *my own* putpixel to
avoid LIBGRX's SetPixel overhead) compare to the polygon scan
routine in LIBGRX (that uses stos to fill scan lines)?

Local cost of these is about $438 ($AUS1 = $US0.65). Still, I'd like to make 
an educated selection. Any suggestions or corrections to my reasoning would 
be appreciated.

cheers
	Michael Snoswell

- Raw text -