From: James Simmons <jsimmons@edgeglobal.com>
  To  : ggi-develop@eskimo.com
  Date: Mon, 2 Aug 1999 16:36:38 -0400 (EDT)

Re: Matrox GGI accellerator

On Mon, 2 Aug 1999, Rodolphe Ortalo wrote:

> Jos Hulzink wrote:
> 
> > Writing the ViRGE accelleration code, I took a look at the Matrox driver.
> > The first thing I saw was a mmap of the accelleration registers in the ggi
> > driver ! (In other words: Every user has access the accelleration
> > registers (including DMA command registers) and mess with the system.) I thought
> > this was one of the reasons why Linus has bad thoughts about ggi....
> 
> Not exactly. In fact, one may even say that it's the opposite...
> It's because we think that full and blind userspace reg. mapping is
> bad that some people think we want to put all the graphic
> management code _inside_ the kernel. (We do not WANT that. But
> safety and security often IMPOSES to put much of the regs. access in the kernel
> IF you want good security properties. The matrox userspace lib. is
> explicitly for those WITHOUT security needs.)

They know that accel handling, not accel registers belongs in the kerenel.
That is the distiction that has to get across. Their has been some
discussion on this. In fact I had a talk with one of the kernel developers
today about this. The BIGGEST thing is the need for proper virtualization
of the accel engine. Security naturally comes out of this. I have been
working on the design for /dev/gfx to deal with such issues. I'm modeling
/dev/gfx after the way it works on SGI workstations. RIght now if I where
to start 3 OpenGL programs in X windows and if all of them bang on the
registers at the same time it would surely hose the machine. A per process
access to the accel engine needs to be set up. With /dev/gfx I plane to
have so you allocate a window in the framebuffer for accel work. This
enables you to use /dev/gfx with or without X windows with the same
perforamce since in X windows you are opening /dev/gfx to work with a
window instead of going threw the X server just like its done on SGI
stations. Plus with the window idea you can mmap the zbuffer the size 
of the window. Even if the card only allows a z buffer the size of the
mode /dev/gfx will only mmap the window area of the zbuffer. This way
each window area can belong only to a specific process. The problem I'm
have is with window overlapping. As for mmap the accel registers
themselves. Well thats tricky. One we have to make sure the accel engine
and the framebuffer are not hit at the same time. This is the hardest
part since I'm no guru with the mmap system. As for mmaping dangerous
registers well I was thinking of having a ioctl call that returns a map of
the registers and need mask on these registers. So for example you have

struct gfx_registers {
	line_x 0x34;
	line_x_mask 0xff12;
	line_y 0x35
	line_y_mask 0xff13;
	...
        ...
}

Where line_x represents the offset from the beginning of the accel MMIO
region. Feedback if this is a good idea. What I trying to do is provide
the programs where to program and not to good into areas he/she shouldn't.

> Jos: we've made exactly the _same_ remarks as you with respect to
> security and safety as opposed to userspace regs. mapping for now...
> well... several years !

As have I inside the linux kernel camp.

> I really think that pingpong buffers are the best way to go, given the graphic
> card hardware problems that prevent us to mmap fully to userspace without
> compromising safety on the one hand, and the latency of ioctl on the other
> hand (this is not to neglect even if I agree that ioctl are not so bad
> in practice - especially for 2d ops.).

Hum. Can you expalin in detail the ping pong method. I sort of have a
idea on how it works but not quite. Thanks.