From: teunis <teunis@computersupportcentre.com>
  To  : ggi-develop@eskimo.com
  Date: Mon, 17 Aug 1998 17:21:29 -0700 (MST)

Re: 3d

On Mon, 17 Aug 1998, James A Simmons wrote:

> On Mon, 17 Aug 1998, Marcus Sundberg wrote:
> 
> > > I like to see library independent accelleration. Threw ioctl not special
> > > library stubs. 
> > 
> > Besides the fact that ioctl()s are not exactly the fastest way to
> > communicate with a GFX accelerator, having a generic ioctl() API
> > for 3D acceleration would bloat the kernel way to much without
> > gaining anything compared to having a small HW driver in the
> > kernel and a library to interface it.
> 
> Yes but fb doesn't have a accel buffer like /dev/graphics.
> 
> If you do good code this bloat can be very small. 

Yeah - possibly up to 512K.  Still a bit much for Linux.
Yes a simple rendering stack can be done in (thinking) <8K, but that
doesn't mean that yer typical modern accelerator (ie: Permedia) can be
done so easily.  (and you are stuck with just simple rendered triangles
with maybe a Z-buffer if you're feeling happy :)

Though here's something:
	How about a microcode IOCTL interface.  Just a standard way
	of forwarding microcode into/out-of a graphics card.
	- This is for those programmable cards (ie: 3DFX,Permedia,...)
	! Oh - and some kind of back-hooks (RT-Linux?) to hook responses
	  from videocard into a kernel-service. Simple use (many
	  videocards) is IRQ handling on video-refresh.  Complex could
	  include DMA Accel-handling and hooks from 3D rendering engines :)

What do y'all think?

G'day, eh? :)
	- Teunis