Date:	Mon, 6 Sep 93 11:59:15 CST
From:	(csaba AT vuse DOT vanderbilt DOT edu) <csaba AT vuse DOT vanderbilt DOT edu>
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: Fastest VLB graphics card for writing pixels

On Mon, 6 Sep 93 16:14:50 CST,
  Michael Snoswell writes:

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

The GrSetPixel function is not really optimal for this purpose since it 
does clipping and then dispatches to a low-level mode-dependent video 
memory access routine. Since you are using only the 256 color mode, 
accessing video RAM directly via a (char) pointer from your scan line fill 
code would help a *lot*.

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

Actually, for a Z buffered scan line fill the speed of the video card 
probably does not matter that much. You are essentially replacing the 
"rep stosb" instruction of the 2D polygon scan line fill with a software 
loop which has to do a lot more: (1) check the Z buffer, (2) fill pixel 
and update Z buffer based on the test result, (3) interpolate the new Z 
value for the next pixel, and (4) update pointers, counters, etc... Even 
with the tightest assembly coding you are looking at a loop of 10-20 
instructions, of which *only one* is storing a single byte in video RAM. A 
real slow card (like a Trident) with tens of wait states will hurt you even 
here, but don't expect too much from replacing a 6-8 wait state card with 
one with 2-3 wait states.

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

The STEALTH driver does not use anything at all except for some int 10h 
BIOS calls. It only sets the video mode and reports the cards type/mode 
parameters to the library. The *library* indeed uses the S3 accelerator 
command set to draw lines, fill rectangles, do bitblt-s, etc. However, it 
*does not* use the hardware polygon fill for one simple reason: you lose 
half of your colors if you use it. (On the S3 you have to draw the 
outline of the polygon in one bitplane and then it fills the polygon for 
you in the other seven planes.) 

The S3 *does not* have any accelerator functions for Z buffered scan line 
fills.

The STEALTH VLB is an excellent card. If you also want to run Windows, 
etc.. on it then it is worth it. However, for Z buffered polygon fills it 
will not be any faster than, say an ET4000 VLB card. (But it will not be 
slower either..)


>cheers
> Michael Snoswell

Csaba Biegl
csaba AT vuse DOT vanderbilt DOT edu

- Raw text -