From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Mon, 16 Aug 1999 02:42:10 -0700 (PDT)

ping-pong buffer support committed to CVS

	The PP buffers are here.  To try them, edit default/kgi/genkgi.h
and #define GENKGI_USE_PPBUF (it is off by default).  Then rebuild both
LibGGI and your KGIcon driver and run some LibGGI programs.  Notes: 

* Only drawbox() and drawline() are handled right now in the genkgi
helper.  I'll have them all supported soon.  Also, when PP is enabled, any
accels unsupported by the KGI driver will be ignored - I need to probe all
accels via ioctl() at genkgi init time because PPbufs have no
back-channel.  This will be fixed soon. 

* SYNC mode is actually a little bit slower than with ioctls, because you
are sending one accel command at a time which negates the advantage of the
PP FIFO, but my fault handler call gate is not optimized yet and as such
is a little slower than the kernel's ioctl call gate.

* In ASYNC mode, you get the full speed but context flushing is not yet
synchronized with the accel command queue so anything that uses ASYNC
(XGGI unfortunately) looks messed up.  This will also be fixed soon,
either with a new ACCEL_FLUSHGC kgicommand or with fault-locking.  Or if
anyone else has any ideas here.... 

* The virtual linear FIFO returned by mmap() is currently set to 4MB, but
since we only ever have to allocate two physical pages it can in theory be
as long as the kernel will let it be.  Huge values should be possible. Try
changing the default size in default/kgi/visual.c and see how it affects
performance.  An munmap() and mmap() call are both necessary when the end
of the PP FIFO is reached, to remove the old mappings.  Too bad I could
not use fast_unmap_page_range in a module....

* The ASYNC PP performance is not yet close to what it will be (it is
about 2x ioctl() speed on my box).  Everything is still very unoptimized
right now - there are unnecessary copies in both kernel and user code,
command fragments are not yet supported which adds lots of overhead, the
fast_[un|re]map_page_range functions cannot be used in a module which adds
LOTS of MM overhead (|-<), and eventually all the tight spots will need to
be written in assembly for maximum optimization.

	So there it is.  Everyone, go beat the hell out of this stuff and
send me bug reports (code would be nice too...) so I can stomp all the
bugs out.  Once this is working, I can start working on GGIMesa+PPbuffer
support.

Jon

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