From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : Brian S. Julin <bri@tull.umassp.edu>
  Date: Fri, 6 Aug 1999 02:00:25 +0200

Re: Accel command queues (was Re: Matrox GGI accellerator)

> First off I agree strongly that the buffer should pass commands
> in the driver's accel command language, that is, the libGGI
> userspace part should do the translation of primitives into
> something resembling register accesses.  

This is IMHO not a very good idea. It strongly depends on the cards
protocol, if that makes sense. An abstract protocol might save space 
in the buffers thus optimizing throughput.

Let me explain my position a bit:

1. The translation between a LibGGI* call and the card register accesses
has to be done _somewhere_.

2. It is irrelevant to performance, if this translation happens in kernel 
or userspace. It uses the same code, so the assumption should hold
for all practical cases.

3. The system is supposed to be safe.

Now if we have the choice between:

1. Send abstract commands to kernel -> decode them -> execute them.
and
2. Decode abstract commands -> send to kernel -> check them -> execute them.

1. is faster, as it saves the "check them".

Considering that the abstract commands will often be more compact in the
transfer representation, this is another argumnet for 1.

The only advantage of 2. I see is that "check them" is often less code than
"decode them". This gives for a less complex kernel driver and thus for a
more stable one.

My choice would thus be:

a. If we can safely export the accel regs: fine. We can save the goto-kernel.
b. Use 1. for all relatively simple commands. This doesn't impact stability
   usually, as the code is trivial and not too big either for those that
   worry about kernel size.
c. Commands that need complex setup calculations should use 2. to avoid
   putting complex code in the kernel without need.

Note, that b and c mix well, so it's not an either-or, but finding a well
balanced solution.

> It was mentioned that 
> having the KGI driver filter these accesses would be a hassle --
> well the driver authors are free to make the filter as restrictive as 
> they want, 

... thus as well making the driver complex, what is what they should help
avoiding. One should keep a good balance in between.
If filtering gets more complex than just doing it straight away, something
is wrong.

> Second, IMHO we need to have accel buffers work independent of 
> the mechanisms they use (IOCTL, MMAP, MMAP+ping-pong, whatever.)

Yes. This is handled in the OS glue layer.

> Maybe I'm overly adverse to wheel reinvention, but it seem to me
> it would be very good if the drivers could just hook their
> queue management onto one of these mechanisms through a simple
> #define or something.

They shouldn't even know how the commands came in. They should just accept
queue commands.

> Also the queues need to be more bidirectional so that result
> codes from the engine can be used in userspace when handy.

This is very difficult usually due to the asynchronous nature of queue
execution. A "backward queue" with requested answer codes would help here.

> In short, driver authors should be concentrating on how to
> manage their chipsets, not how to reimplement a ping-pong.

Yes. OS glue layer is there for that.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =