From: Morten Rolland <Morten.Rolland@asker.mail.telia.com>
  To  : ggi-develop@eskimo.com
  Date: Mon, 16 Aug 1999 11:49:21 +0000

Re: Ping-pong buffers on KGIcon are here!

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?

Wouldn't unmapping/faulting/sleeping/remapping involve a rather
bad performance hit when the batched accels queue is short?

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...)

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?  Will this be
automatic as as well (Emptying the ping-pong buffers
when writing to the frame-buffer) ?

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?) ?


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?

This may require a change in the GGI-API, which is bad at
this point, but personally, I don't like the idea of
unmapping/mapping the framebuffer because of the fact that
a program can't know in advance if it will run into
performance trouble or not - this is dependant on the
underlying video-hardware and driver, and how well GGI
makes use of that driver.

So, if you ask me, I'd say: Don't be too smart with
framebuffer locking, even if it breaks the GGI API.
Keeping the kernel-side small, nice and elegant should also
be a concern.

Regards,
Morten Rolland