Jon Leech <ljp@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, Apr 23, 2000 at 01:22:33PM -0800, Kendall Bennett wrote:
> > Hi Guys,
> >
> > I am curious if there is any news on whether the optimised software
> > rasterisation stuff from SGI OpenGL for Windows will be added to the
> > SI? Or news on whether the optimised geometry stuff fom OpenGL for
> > Windows and/or the SGI DDK will be added to the SI?
>
> We are willing to release the ogcode for software
> rasterization, but understand that it will be a reasonable amount
> of work to get it operating with the SI. So before going to the
> effort of pulling the code into the oss.sgi.com tree, it would be
> really helpful to have someone commit to, or at least express
> substantial willingness to, make it work in the SI.
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?
> I am so swamped with ARB related matters that I have trouble being
> responsive on this mailing list, much less getting to write much
> code - although we're planning to dedicate more engineering cycles
> to the ogl-sample work shortly.
Great! It looks like we both might get freed up to work on this
around the same time then ;-)
> If you're interested in helping with this, let me know. The
> optimised geometry code mostly comes from other companies. We have
> discussions underway which will (hopefully) result in those
> companies open sourcing this code, although I can't speak to just
> when it might happen.
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. Without the optimised geometry code we may be better off
staying with Mesa, at least initially.
Although perhaps another alternative is porting some of the Mesa
source to the SI for this type of thing, but it would be much easier
to start with stuff that is already designed to fit into the SI.
> > Item 3 is something I am not very familiar with internally in the SI,
> > and I have not had a chance to dig into it recently. From what I have
> > heard, converting the SI to work with hardware is quite a significant
> > amount of work. Is that true? Are their plans to develope a better
> > device driver layer for the OpenGL SI (perhaps based on the SGI
> > OpenGL DDK)?
>
> Not specifically. We do have some other discussions going
> regarding open sourcing of certain vendor drivers based on the SI,
> which might help set such a direction. To a certain degree I think
> of the "device driver interface" as the OpenGL API itself. Trying
> to specify a rasterization-level hookout is not very forward
> looking, with almost all interesting new chips providing T&L. Am
> open to suggestions, though.
Sure, for the future and to support hardware T&L, the OpenGL API
really is the device driver layer for the most part. However although
all interesting new hardware has hardware T&L, there are still
literally millions of good boards out there in the field that don't
have this! Hence we need to way to ensure that we can provide good
solutions for legacy hardware (hell, are we *already* at the stage of
calling the TNT2 and Voodoo3 legacy hardware!).
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).
An abstract API for all this stuff is certainly possible. If it
wasn't, Direct3D immediate mode would not exist ;-)
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 |
+---------------------------------------------------------------+
|