From: James A Simmons <jsimmons@acsu.buffalo.edu>
  To  : ggi-develop@eskimo.com
  Date: Mon, 17 Aug 1998 21:59:46 -0400 (EDT)

Re: 3d

On Mon, 17 Aug 1998, teunis wrote:

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

Were do you get this number from ? I think you and alot of other people
misunderstand what I am suggesting. I'm not asking to put a OpenGL like
library into the kernel. That would be insane.

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

Yes. That is what I am suggesting.

> 
> 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?

Bingo. This is what I'm talking about. Here is my idea.

Idea I.

   The ability to allocate frames and tell what type of frames they are.
  Basically saying hey give me three frames. One display frame, one
  zbuffer, and one double buffer. Most Hardware support this. Lets not
  over do it for types of frames.

Idea II.
   As for primivites. Support arbitratory lines. Support span lines (aka
  horizontal lines). Do NOT support things like polygon or B Spline
  curves. This would bloat the kernel but a library could break down a
  polygon into span lines which is accelerated into the kernel. Do support
  boxes and triangles but thats it. Triangles are nice because a well
  written library could make curved shapes from triangle strips. B Spline
  and things like this can be broken down by the library into basic lines.
  With these shapes just support factes. Not whole objects like a 3D box
  at one time.  

Idea III.
   Support alpha component in color. Support gourand shading. Do not
  support texture mapping. This is the really mess out there. As for
  lighting effects stay away from this as well. Although I have a
  interesting idea to handle this. This could be simulated by a color
  function table. Sort of like how the 3Dfx cards do it. They can't do
  lighting but have a color blend function table. Also looking at the
  ATI Mach64 Rage 3D card has a similar function table. I will have to
  work on this later. 

Thank you. I hope this clearify everything.

PS. How is the linux Makefile system coming. Please we need to get this
ready in the next few days. I'm home all day tomorrow so I want to write 
the Makefile system. We need to get are drivers into the kernel. This is
numbe one to do. Once in the kernel we can continue on improving the
drivers.