From: Brian S. Julin <bri@tull.umassp.edu>
  To  : Jos Hulzink <josh@stack.nl>
  Date: Wed, 4 Aug 1999 09:19:56 -0400 (EDT)

Re: Accelleration: A summary

On Wed, 4 Aug 1999, Jos Hulzink wrote:

> The data can consist of two things:
> 
> 1) Commandstructures which have to be interpreted by the kernel
> driver. Negative item here is that this makes the kernel accellerator
> bigger compared with the 2nd option. Positive is that the kernel only has
> to check coordinates for security (If this can crash the system,
> otherwise even that might be omitted). Note here from me: 2D accelleration
> in kernel doesn't take that much space, see for example the ViRGE
> kgicon driver.
> 
> 2) A list of registers and data. Positive here is that the kernel driver
> can be very small, for no interpretation is needed. Negative is that the
> register and data must be checked. (No DMA commands allowed, maybe
> coordinate checking if this can crash the video chipset) 
> 
> Am I right so far ?

Yes.  There also should be an IOCTL that can force a flush of the buffer 
before it is full.

For #1, though, you may be underestimating the simplicity of the command
set... LibGGI's set may be simple, GGIMesa and LibGGI3D's won't be.  The
kernel driver needs to support GGI extensions as well as LibGGI itself.

For #2, someone mentioned a "state mapping buffer".  My best guess as
to what was meant is the kernel driver keeps a mirror in RAM of what
is in the accel registers so it can validate the commands as necessary
and/or save/restore the accel state during a VC switch.  This also
prevents the need to read back out of the accelerator across the 
bus.

As far as validating coordinates, there's not much difference between
using a "kgicommand" style and register access, since the final 
register access command usually is the accelerator's equivalent of
"drawbox" or "drawline" or whatever.  The only difference is that you
feed the parameters first, and you have to screen for illegal
register sets (e.g. don't let them set the DMA transfer bit).

--
Brian