From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Mon, 9 Aug 1999 21:12:55 +0200

Re: Matrox GGI accellerator

> > It cannot be done without hardware support. You have only two choices on
> > that matter:
> > 
> > 1. Do not allow direct mapping of video RAM. Always go through an accel
> > protocol, which you can clip in software.
> > 
> > 2. Accept the possibility of "crosstalk" between the windows and eventually
> > between the window and the root window. As I outlined, this is not a real 
> > concern with X windows anyway, as one can mess up the screen "legally" by
> > creating new windows or drawing on the root window as well.

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

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =