Date: Mon, 6 Sep 93 11:59:15 CST From: (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