From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Mon, 16 Aug 1999 11:43:11 -0700 (PDT)

Re: Ping-pong buffers on KGIcon are here!

On Mon, 16 Aug 1999, Morten Rolland wrote:

> Hello,
> 
> Jon M. Taylor wrote:
> > 
> >         The answer is what I wrote above - unmap the framebuffer while
> > accels are being processed, and remap it after the accels are done.  Then
> > set up a nopage() handler on /dev/fb that will catch the page fault when a
> > process touches the framebuffer while it is unmapped, put the process to
> > sleep, and wake it back up after the accels are done and the framebuffer
> > has been remapped.  Then the process continues to access the framebuffer
> > normally, and has no idea that it was put to sleep for a while.  This way,
> > the process can interleave accels with framebuffer accesses however it
> > wishes to, and no special handling is required in the process' code.
> > Everything is taken care of in the kernel.
> 
> This method could be made to work very well for applications using
> either accels *xor* writing directly to the framebuffer, but how
> about an application that (accidentially) mixes the two rather
> closely?

	There is no 'correct' solution to this problem, then.  Either you
take the performance hit, rewrite your code so that the FB acesses are more
intelligently laid out, or you turn off the FB locking and live with it.  
Any API will have these same restrictions.
 
> Wouldn't unmapping/faulting/sleeping/remapping involve a rather
> bad performance hit when the batched accels queue is short?

	What alternative is there?  You have to do _something_.  

> With 4-8MB of framebuffer mapped, 
> some 1024-2048 enteries in
> the paging tables needs to be updated (unless I'm mistaken - and
> you can unlink one step up the tree), and the TLBs flushed?
> On a multiprocessor system, there is the risk of having to
> flush TLBs on several processors, unless the kernel is smart
> enough to stall the ones not needed (I hope it is...)

	Hm.  Well, the alternative is to require usersapce to call an
acquire_fb_lock() type function, like GLIDE does. 
 
> The following are thoughts that I have without knowing too
> much about the internals of either the kernel nor GGI, so
> please bear over with me if I'm being ignorant:
> 
> When a ping-pong buffer only gets half-filled before the
> application/GGI starts writing the framebuffer, what then?
>
> The accels needs to be flushed, yes?  

	Yes.

> Will this be
> automatic as as well (Emptying the ping-pong buffers
> when writing to the frame-buffer) ?

	I would assume so.
 
> If this is so, how do GGI and the kernel syncronize the
> ping-pong buffer (by always keeping an "end of accels" marker
> at the end, and always go round-robin?) ?

	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.
 
> Why not require the application (and GGI-lib functions)
> to make a check and sleep if accels may be running still, as
> suggested earlier in this thread?

	Yes, a select() on /proc/kgi/kgicommand would be possible.  However,
this requires that fbcon-kgi.c be able to sense when the _hardware_ accel
engine is busy/idle, which is a driver-specific task.  I need to think about
the best way to do this. 

Jon 

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