From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 12 Aug 1999 20:24:58 -0700 (PDT)

Re: Matrox GGI accellerator

On Thu, 12 Aug 1999, James Simmons wrote:

> > Either they have separated or protected z-Buffers. That fall in the category
> > HW-support, or you do 2. (which vialoates your prerequisite), or you do 1., 
> > which might be a bit slow, as you will then have to do calls through the
> > accel layer to handle the Z-buffer. The accel layer has full clipping lists
> > and can enforce them.
> > 
> > There is a third awkward possibility: You provide virtual z-Buffers to all
> > of the processes. For this, you link into scheduling and remap the buffers
> > whenever a process gets (de-)scheduled that uses them and you save/restore
> > the contents at that time. This is basically the same as what you do with
> > normal RAM when swapping, or with the CPU regs.
> 
> Actually I though about the third possibility. Another possibility I
> though of was using hardware clipping. Doh! That will not work. Alot of
> hardware allows you to write to the framebuffer thats outside the
> hardware clipping boundaries. That probably includes z buffers etc. So the
> three possible method looks like the best situation. Of course thats down
> the road and that would be hard to get into the kernel. 

	This was the primary reason I implemented the /proc/kgi system, 
which maps each buffer through its own file.  File locking semantics 
ensure that only one process can touch the hardware buffer at one time.  
Of course this doesn't help you virtualize the buffers, but since the 
framebuffer device isn't virtualized anyway....

Jon

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