From: James Simmons <jsimmons@edgeglobal.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 12 Aug 1999 21:32:03 -0400 (EDT)

Re: Matrox GGI accellerator

> > > 1. Do not allow direct mapping of video RAM. Always go through an accel
> > > protocol, which you can clip in software.

Actually I was thinking of not allowing the opening of /dev/gfx when
/dev/fb is mapped if the hardware canhandle it.

> > Then how do you suggest we handle the following situation. I'm running two
> > OpenGL programs in X windows. I don't want process one being able to
> > write into process two z buffer. 
> 
> 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.