From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Tue, 11 May 1999 12:02:30 -0700 (PDT)

Re: MMIO accel with kgicon drivers.

On Tue, 11 May 1999, Marcus Sundberg wrote:

> Jon M. Taylor wrote:
> > 
> > On Mon, 10 May 1999, =?iso-8859-1?Q?Jonas_Borgstr=F6m?= wrote:
> > 
> > > Hi, all
> > >
> > > I have recently tried XGGI, and it works great. I first tried the matroxfb
> > > driver, it was fast but I didn't manage to get any resolution bigger than
> > > 640x480. And after using fbset a while I had to reboot the computer.
> > > After that I tried my old Matrox Millennium driver, and it worked in all
> > > resolutions but, because it uses ioctrls to accelerate it is a lot slower
> > > than the matroxfb driver that uses direct mmio accel.
> > >
> > > So, what should I do:
> > >
> > > Should I try to use the matroxfb and somehow get my resolution
> > > (1024x768x16), but I like kgicon with and the generic monitor driver and
> > > setmon.
> > >
> > > Or should I update my driver to use mmio acceleration?
> >
> >         MMIO acceleration is a security hole.
> 
> Not anymore than fbcon already is.

	fbdev drivers can use ioctls.  They do not have access to the KGI 
internal structures and management framework, but they can still catch 
and handle per-driver ioctls, correct?
 
> > What is really needed for a
> > good solution to this problem is accel-operation FIFOs to reduce the
> > number of kernel-user transitions, as this is what kills performance.
> > Steffen's new KGI 0.9 design has exactly this, for exactly this reason.
> 
> The old Dali KGI had it too, but unfortunately there was only one
> driver that used it... (the Mystique)

	Are you talking about the 'pingpong buffers'?

> But in any case mapping the accel registers to userspace should
> always be possible. 

	Well not always - I certainly cannot do that |-/.  Unless you mean
'possible within the overall KGI[con] API framework'. 

> For KGI 0.9 it probably will require root privs
> (or my preference - a separate device which you can give whatever
> permissions you want) 

	I would do any such non-framebuffer mappings through device-specific
/proc entries created on the fly.  I am considering using such a scheme for
my Creative driver - accel buffers, texture buffers, vertex buffers, MMIO
registers (when appropriate) etc can all be handled this way and it keeps the
fbdev interface clean of driver-specific stuff.  Perhaps ioctls could be
bound to each /proc file as well so that /dev/fb does not have to handle them
all.  This use of multiple ioctl entrypoints could provide a speed boost, but
I do not know if /proc entries are normal device files which handle
ioctls....

Jon

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