From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Thu, 19 Aug 1999 10:53:39 +0200 (MET DST)

Re: VC Switching

Hi !

> And while I'm playing Devil's Advocate...  Ping Pong buffers.  I
> understand how they work, but not _why_ to go to the extra trouble of
> using page faults, instead of just calling some write() function which
> can pass a big block of accel commands to the driver.  What is their
> advantage ?

IMHO not so much, when implemented in the way they are being discussed now 
(though that is not a problem, as it can easily be changed to what I will
outline in the next few paragraphs once it is there and working).

I think the real advantage of this method is, that it has minimum latency
and maximum parallelism of CPU and Accel engine, if it is implemented in
the way I will describe now:

The protocol run on the PP-buffers must be block-oriented, with an atomic
"block-complete" flag somewhere in each block.

I have outlines such an approach earlier: You use a chain of block lengths, 
just like our event system uses. The size of any event can be determined by
its header, what allows to ignore unknown ones (though this isn't an issue
here).

If you now write such blocks like this:

oldptr=tailptr;
tailptr++;// leave space for the size. We _know_ there is '\0' in there now.
size=blocksize;
while(size--) *tailptr++=*block++;
*tailptr='\0'; // This is the '\0' for the next time.
DO_ATOMIC(*oldptr=blocksize;);

You can watch the queue from kernelspace using lowwater interrupts and 
similar.

This allows to find out instantly, if new requests have been queued,
whenever the kernel feels like it.

The accel can run freely, while the CPU keeps queueing new commands.
When the accel is about to get idle, it can issue a "lowwater" interrupt
(most good cards have one, or at least an accel-idle).
The driver can the pick up the queue, which is still being filled and
add a bunch of extra commands to the accel queue.

This gives almost zero latency, as the command is available for execution
as soon as it is completely queued, not as soon as a page is full.

CU, ANdy

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