From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 4 Aug 1999 13:46:40 -0700 (PDT)

Re: Accelleration: A summary

On Wed, 4 Aug 1999, Jos Hulzink wrote:

> Hi,
> 
> I hope this message is not seen as conclusion, but I had to get the huge
> amount of mails on this topic clear to me and I want to know if I'm right:
> 
> Ping-Pong buffers are implemented by taking two memory pages (isn't that a
> little huge for 2D accelleration ?). 

	Well, it cannot be any smaller |->, since you need always one page in
the kernel and one page in userspace.  And they need to be true hardware
pages, since we use MMU trapping to call into the kernel and tell it to flip
the buffers.  It will be more efficient on architectures other than x86,
where page sizes might be more flexible.

> One of the pages is mapped into user
> space, the other only in kernel space. For this needs segfault trapping in
> the kernel, KGICON is not suitable, but KGI is the way to go.

	Actually, I have looked at this lately and I really do not see why 
this cannot be done in KGIcon as well.  Steffen, please enlighten me if I 
am missing something, but can't we just use the nopage method in the 
vm_operations struct to handle page faults in the ping-pong buffer?  If 
we can do that, we should be able to handle all of the buffer swapping 
and page remapping right from fbcon-kgi.c
 
> User level drivers get a remapped region, with size 2x the memory page
> size. This mmapped region is defined by a base pointer. Writes to this
> region are done in linear (increasing) order with wrap around after 2x
> memory page size, like:
> 
> Offset = (Offset + CommandSize) & (2 * Pagesize - 1)
> 
> Each time a write is done at the start of a new page (that is at offset
> "0" and "Pagesize"), a PageFault is generated (caused by the fact that the
> kerneldriver has unmapped that page). This pagefault is caught by the
> kernel driver which maps the page, unmaps the other page, and tells some
> accellerator procedure it has work to do. That procedure takes the data of
> the unmapped page and does something with that data.

	Yes, with the note that you do not have to fix the size of the
virtual userspace region at 2 pages.  The larger the size of the virtual
userspace region, the less checking for buffer-full conditions will need to
be done on the userspace side.  In fact, for 3D applications I would say that
two pages in far too small.  But the nice thing about this scheme is that you
do not actually need to allocate more than two physical pages, no matter how
long your virtual userspace buffer is!
 
> The data can consist of two things:
> 
> 1) Commandstructures which have to be interpreted by the kernel
> driver. Negative item here is that this makes the kernel accellerator
> bigger compared with the 2nd option. Positive is that the kernel only has
> to check coordinates for security (If this can crash the system,
> otherwise even that might be omitted). Note here from me: 2D accelleration
> in kernel doesn't take that much space, see for example the ViRGE
> kgicon driver.
> 
> 2) A list of registers and data. Positive here is that the kernel driver
> can be very small, for no interpretation is needed. Negative is that the
> register and data must be checked. (No DMA commands allowed, maybe
> coordinate checking if this can crash the video chipset) 
> 
> Am I right so far ?

	Pretty much.

Jon

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