Jon Leech <ljp@xxxxxxxxxxxxxxxxxxxx> wrote:
> [re "online generated" aka ogcode for rasterization]
> > I am willing to work on this, and will probably get the time to work
> > specifically on this in about a month or so. I have copies of the old
> > SGI OpenGL for Windows source code hanging around somewhere, but I
> > gather from what you are telling me that the optimised geometry code
> > will need to be ported to the SI? I thought the SI and the OFW were
> > very similar?
>
> They are very similar. But the SI has had quite a lot added to
> it since 1997, the build structure is very different, and most
> significantly, the SI only builds for X/Unix in the current build
> structure (although I certainly encourage people to figure out how
> to build it for other environments and let us know how - embedded
> platforms are of particular interest to me as a future direction
> for 3D, and most of those are not going to be running X11 - I hope
> :-)
>
> I'll get the ogcode into the CVS tree over the next couple of
> weeks.
Cool. So the ogcode is all owned by SGI but the optimised geometry
stuff is not?
> > I am very interested in the optimised geometry code, and if there is
> > a commitment to get this into the SI sources then we would probably
> > spend our efforts working on the SI as opposed to Mesa to get things
> > working.
>
> I think it's likely to happen fairly soon, but since it's not
> SGI's decision (actually two separate decisions by two separate
> companies), I can't give you a date. Will keep pushing from my end.
Great. Let me know the outcome of this.
> > So my idea is that we need a layered device driver model. One layer
> > is for cards with only 2D acceleration, and most does all the
> > rendering in software (with perhaps an accelerated screen clear and
> > 2D primitives ;-). The next layer is for rasterisation only hardware
> > and provides a device driver model for that. The next layer above
> > that is for harware T&L, where a large portion of the OpenGL API
> > functions go directly into the device driver layers (once you do all
> > the usual OS specific stuff for managing threads etc).
>
> Wasn't this the idea behind SciTech's Inertia/Nucleus driver
> architecture? Where does that stand? Maybe it could be used as a
> starting point.
That is exactly the idea behind our Nucleus device driver model. We
already have the Nucleus layers, so what we are really doing it
working to add a device driver model either to the SI or Mesa that
will interface directly to our Nucleus drivers.
Regards,
+---------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+---------------------------------------------------------------+
| Kendall Bennett | Email: KendallB@xxxxxxxxxxxxxxx |
| Director of Engineering | Phone: (530) 894 8400 |
| SciTech Software, Inc. | Fax : (530) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+---------------------------------------------------------------+
|