From: James A Simmons <jsimmons@acsu.buffalo.edu>
  To  : ggi-develop@eskimo.com
  Date: Fri, 21 Aug 1998 08:23:01 -0400 (EDT)

Re: libggi internals (Re: LibGGI3D RFC)

> > This gives you three options:
> > 1. Extend the KGI API with 3D functions and use the same
> >    driver for 2D and 3D.
> 
> 	This is the way to go, IMHO.  Take your existing 2D KGI drivers
> and add 3D drawing ioctls. 

I agree. 
 
> > 2. Design a new kernel-driver API for your 3D drivers, which
> >    also contains 2D functions.
> 
> 	Why, when we already have KGI?  fbcon/fbdev *can* be used for 2D
> and 3D acceleration (and the fbdev LibGGI target, too), but KGI is just
> plain better designed. 
> 
> > 3. Design a new kernel-driver API for your 3D drivers, which
> >    only deals with 3D.
> 
> 	This might be necessary to flog the absolute most performance out
> of 3D hardware (ioctls == slow sometimes), but if this is to be done it
> should be saved for later, after we have something working first.
> 
> > The third option would cause problems for cards that integrate
> > 2D and 3D as you would have two drivers access the card. 
> 
> 	Either you would need to just toss out the 2D stuff and have a
> 3D-only specialized KGI driver, or KGI would have to multiplex the
> hardware between two or more separate drivers.  This isn't a bad idea in
> principle - imagine the accel driver as actually being a separate driver
> module .o file.  It would allow for mix 'n match driver modularity, much
> like we have now in userspace with LibGGI.  But this would be a VERY
> complex system, and quite different from what we have right now.  I think
> this needs to go on the to-do pile along with vblank syncing, etc.  Save
> it for later. 

Agreed. Lets star with ioctl and then more to more efficient system.