From: Brian S. Julin <bri@tull.umassp.edu>
  To  : ggi-develop@eskimo.com
  Date: Tue, 3 Aug 1999 21:40:56 -0400 (EDT)

Accel command queues (was Re: Matrox GGI accellerator)

My 2 cents on the accel buffer stuff: 

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.  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, as long as the primitives can be implemented within
those restrictions, and the userspace code is programmed not to 
exceed the restrictions, so I don't think this is very relevant.
It is not necessary to support every register in the accelerator
engine and some can just be filtered out entirely, simplifying
the driver overall.

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

We need some quality thought on a "standard" that abstracts the 
mechanism on both the userspace and kernelspace ends, and takes care
of all the various problems with each mechanism internally without
the driver author needing to worry about it.  That is, the 
userspace code should be able to call an "append_to_queue" command
on a queue and know that the call will put the commands on the
queue, not fall off the end, and not tangle with data that is
being changed or read by another thread/processor, and on the 
kernel end, the driver should be able to call a "get_from_queue"
knowing that the data returned will be valid (not partially written)
and it won't read past the last complete command on the queue.

Also the queues need to be more bidirectional so that result
codes from the engine can be used in userspace when handy.
Note too that Steffen raises the possibility of having more
than one queue with different priorities.

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

All this requires a lot of knowlege of race conditions, SMP,
atomic access, etc. and is complicated by the user/kernel space
issue.  But I've seen enough talent on this list that if we were to 
rub our noggins together long enough we could come up with something.  
Such would also fit well in the new UDIish KGI structure.

I think we should work an abstraction up that would handle the
cases of IOCTL, a simple r/w MMAPped page, and a ping-pong
system.

BTW, I've slightly improved the sections in the GGHPG on
address spaces, IOCTLs and MMAPs if anyone feels a bit lost
in this discussion, and would welcome any more improvements
from others on the list.  The document is meant to fill people
in on hardware/graphics basics and answers a few of the questions 
about terms that have been raised in this thread.  It could be 
better though.

http://www.calyx.com/~bri/projects/GGI/GGPG/

--
Brian