From: Rodolphe Ortalo <Rodolphe.Ortalo@cert.fr>
  To  : ggi-develop@eskimo.com
  Date: Wed, 04 Aug 1999 10:22:24 +0200

Re: Matrox GGI accellerator

"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 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 ?

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

Rodolphe


PS:

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