From: Rodolphe Ortalo <Rodolphe.Ortalo@cert.fr>
  To  : ggi-develop@eskimo.com
  Date: Mon, 02 Aug 1999 18:17:50 +0200

Re: Matrox GGI accellerator

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

> I know, the driver is still young, but in my eyes, if we want the GGI
> project to be taken seriously, we have to prevent code like this as much
> as possible, or else our opponents will say,'See I can crash the system',
> and they are danm right.
>
> My -not in the CVS tree yet- driver for ViRGE uses ioctl, and will do that
> until I got a real good workaround. Oh, and ioctl isn't that slow, (11 x
> faster copybox in 8bpp mode isn't a bad value for good old ViRGE on a P
> II 233)

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 !
I know the Matrox code export the registers (I did not wrote it, but at the
time that driver was written I was writing the 546x one and well, I followed
the Matrox's development to get some inspiration sometimes).
That decision was taken simply because it was a prototype driver
which intent was to provide maximal performance and evaluate the
feasibility of the approach of a userspace 'hw' lib. inside the libggi framework.
The other part was not written just... well... just because noone did.
Currently, every KGI driver reflects the personal 'style' and motivation
of its writer. (Many of them were written for fun as much as for
real work.) Especially the old ones.

Personnally, with the 546x I programmed only 1 or 2 ioctl accels and then
the development froze for various reasons (new kgi, linux 2.2.0, no user,
libgwt, etc.)
(BTW: I obtained only a x 4.5 factor.... You beat me. Didn't you
forget to synchronize on the END of the drawing ?)
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.).
I'm glad that you reach a state in which you will be able to try that
approach. Few KGI drivers allow that currently.

> Sorry if this mail sounds negative, but after the discussion why GGI isn't
> taken seriously on this list, seeing a driver like this scares me.
> Or am I wrong ?

No. You are right (at least I think so). And we have been criticized for a
long time for defending THAT position. So, don't worry, go on with your
way...
The matrox driver is the exception with respect to other drivers.
I'd say that it was developed in the opposite way (starting by the
end). Or maybe I started by the end... :-)))


Rodolphe (Ortalo :-)

PS: If you don't trust me: look in degas/accel/Cirrus/546x.c ;-)
PPS: Especially if you did not synchronize the hardware blitter
with normal mmapped framebuffer access... ;-) Sometimes, your
drawing may be wrong... (Unless ggiFlush() usage is now correct
everywhere - something that may be much better now than it
used to be.)