Date:	Fri, 16 Sep 1994 12:44:56 +22305931 (WAUST)
From:	Ron Grunwald <rgrunwal AT bluering DOT cowan DOT edu DOT au>
Subject:	Re: Manual VGA access with VESADRV.VDR
To:	Greg Hanssen <hanssen AT netcom DOT com>
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu

On Wed, 14 Sep 1994, Greg Hanssen wrote:

> Hello again!  Just a bit more about the VGA saga..
>   After rebooting my system I tried the 'working' programs again and
> they didn't work.. I must be missing brain cells because I could have
> sworn I had device=vesadrv.vdr, but perhaps I had the old trusty
> paradise.grd in there..  Either way I was back at square 1.
> I hacked into GrPlot down to GrSetPixel then down to GrP8Psomethingerother
> but it turns out I wasn't in 256 color mode at all (duh)  GrP4...
> worked fine so I looked into what it was that got me to 16 color mode..
> turns out the GrSetMode(6,1024,768) defaults to 16 color on the new
> GRX libraries.. I had to use (9,1024,768,256) to specify 256 color mode.
> Now my direct memory access works, but it is EXTREMELY SLOW!
> Now I understand the potential for overhead with VESA and I know
> VESADRV.VDR is slower than my old PARADISE.GRD, but this was rediculous!
> using GrPlot was just as slow.. seems to run faster in 16 color mode
> (which I can use for these programs.. I just assumed 256 color would
> be faster due to simple math (1pixel=1byte).. I guess not)
> So far the best performance (for Vesadrv.vdr) has been 16 color mode,
> using the library functions to plot.
> 
> Any ideas as to why direct 8bit is so slow with vesa?  is the paging
> that bad using VESA?  and why would it be slower than 4bit mode?
> 
> -- 
>   --Greg <Hanssen AT netcom DOT com>      (714)-551-5833         4961 Barkwood
> Zefiro Acoustics: SPDIF interface cards for the PC.       Irvine, Ca. 92714
> 

This sounds like a problem that I experienced some time ago.

I should mention here that all my graphics work so far has
been on a Paradise VGA card, so I'm not too familiar with the
SVGA graphics hardware yet.

However, I have experimented with an SVGA like graphics mode
and found indeed that it is considerably slower than the 
640x400 16-colour VGA mode. The reason for this is that the two
modes operate in totally different ways.

The 4-bit mode uses 4 independent bit planes simultaneously to
generate a single pixel. This approach is very memory conservative.
ie. 1 byte can generate 8 pixels simultaneously.

The 8-bit mode uses what's called the "packed" method of creating
pixels. Here, the actual colour byte gets written into screen 
RAM. With 256 colours possible, it makes this mode very memory
hungry. ie. 1 byte generates only 1 pixel. With a 1024x768
resolution display, 786432 bytes would be necessary to maintain
such a display. Remember that in SVGA modes, only 128Kb is
available to write into adapter RAM. The problem was overcome
by introducing "Bank Switching". This is where graphics starts
to slow down heavily! For each switch of memory banks, the processor
must execute 2-3 I/O instructions to the VGA processor. I/O
instructions are always very slow compared to processor instruc.
speed as they are limited to the speed of the I/O bus.

Now, if each individual pixel write involves computing and setting
the bank number, the resulting graphics slows down heavily, as
I've experienced on my machine. I'm pretty sure that this is the
problem you're experiencing.

The key to achieving fast graphics is to use the VGA processor
as little as possible! Quite ironic really.


To overcome the problem you would really have to design your
own pixel function, and optimize it in such a way that a minimum
number of bank switches are performed. You probably didn't want
to hear this!


Hope this explains things a bit.
  
Regards,
         Ron. 



 ********************************************************************
 | Author.............. Ron Grunwald                                | 
 | Internet............ rgrunwal AT bluering DOT cowan DOT edu DOT au              | 
 | Phone............... (09)273 8027 or (09)273 8468                |
 |------------------------------------------------------------------|
 | Department.......... Information Technology                      | 
 | Division/Faculty.... Operations and Systems Management           | 
 | Institute........... Edith Cowan University, Churchlands         | 
 | Location............ Perth, Western Australia                    |
 ********************************************************************
 "I don't have any solution but I certainly admire the problem!"

 
 

- Raw text -