Index:
[thread]
[date]
[subject]
[author]
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.)
Index:
[thread]
[date]
[subject]
[author]