From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 4 Aug 1999 13:33:10 -0700 (PDT)

Re: Matrox GGI accellerator

On Wed, 4 Aug 1999, Rodolphe Ortalo wrote:

> "Jon M. Taylor" wrote:
> 
> >         I would say that the concept of an accel command FIFO with associated
> > state mapping buffers should be close enough to a perfect approach that any
> > hardware that I know about could be handled well this way...?
> 
> "state mapping buffers" ? What's that beast ?

	The GC (graphics context).  I refer to the page mappings used to 
hold the GC.
 
> >         The bottleneck here is the translation from kgicommands to hardware
> > commands/register writes.  This is why it is _critical_ that the kgicommand
> > interface for a particular KGI driver be able to map closely to the actual
> > hardware command structure, and that the userspace GGI target code can not
> > assume that there will be some kind of generic kgicommands which exist across
> > all drivers.
> 
> Do you have an idea on how to define such 'kgicommands' language ?

	Well, currently in KGI/Dali it is done in kgi_commands.h, based
around ioctls.  Basically you have a range of integers which you partition
into subspaces corresponding to the various driver subsystems (ramdac,
chipset, accel, etc) and then you just #define your commands.
 
> If we want something rather generic, the driver will need to _interpret_
> the command (which may slow him - but I'm not sure it would
> be so slow: the commands are pretty simple). [I'd favour this.]
> 
> If we want something flexible, a userspace lib can simply write
> the _real_ display list commands directly into a buffer given
> to the kernel driver - the the driver 'only' needs to _validate_
> them (by checking there are no false command code, etc.)
> 
> Personnally, I don't know which approach would be best (especially
> wrt. a typical 3D accels commands flow).

	Both, probably.  There will always be _some_ commonality of function
between drivers, but there will always be unique features as well.  This is
why suggest-strings are a good thing, because it allows to easily identify
these common command sets.
 
> > > to mmap a full portion of the register to userspace,
> 
> >        Again, I question the necessity for this.  In the past, we have
> > presented the ability to directly map the registers as an issue of allowing
> > for less safety for those who want maximum speed.  I am increasingly of the
> > opinion that the extra locking required of the userspace code in this type of
> > situation removes any potential for real-world performance gains.
> 
> Wow... I never said that (I never dare to - especially in bad english) but...
> I really agree.
> (Maybe for different reasons: it seems to me that direct hardware programming
> is _really_ very cumbersome and annoying and error prone. The best
> performance gains are not usually obtained through these programming
> techniques... :-) except perhaps for benchmarks.)

	True.  People write benchmarks which do nothing but throw accels at
the driver as fast as possible, see that writing directly to the registers
generates the highest benchmark scores, and fail to realize that vitually any
real-world app (games included) is going to introduce enough latency to wipe
out those gains.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed