From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Tue, 17 Aug 1999 00:23:04 +0200

Re: Ping-pong buffers on KGIcon are here!

> 	Hm.  Well, the alternative is to require usersapce to call an
> acquire_fb_lock() type function, like GLIDE does. 

Yes. This is there and should be used. The operation is very cheap, if
performed in the GC.

> 	Well, currently I prefill the pages with 0xffffffff so that 
> pingpong_exec() can always know when a partially-filled buffer is 
> present, but eventually I will switch to a higher-performance solution 
> which will probably involve tracking the userspace write pointer.

I suggest to do the simple thing: Event-style queueing with atomic
"enabling" of newly written requests.

That is, enqueueing an event looks like:

current=head;
// we _know_ *head==0 here, as you will see later on.
head++;
memcpy(head,mydata,sizeof(mydata))
head+=sizeof(mydata);
*head=0;	// place a new 0 at the tail, which is the one from above
		// for the next iteration.
ATOMIC( *current=sizeof(mydata)+sizeof(*head); );

You get the point: We have a "tailmarker" of "0". The kernel tracks that
one. If it changes, it reads the request and does krn_head+=*krn_head;

So the kernel does:

while(*krn_head) {	/* Do we have new accels queued ?*/

	process_the_event(krn_head+1);
	old_head=krn_head;
	krn_head+=*krn_head;
	*old_head=0;	// Mark old event as processed.
}

The advantage of that method is, that we can make use of lowwater interrupts
to refill the accel queue without the need to have complete accel pages
ready. You can then even save the flush call by just checking back to the
latest command head. If it is 0 and the accel lock is free, there is no need
to explicitly flush. It already happened.

> _hardware_ accel engine is busy/idle, which is a driver-specific task.

No. This needs to be abstracted. See the shared user/kernel locks I talked
about. It's how SGI does it IIRC.

CU, ANdy

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