[Top] [All Lists]

Re: [ogl-sample] Future of the SI?

To: ogl-sample@xxxxxxxxxxx
Subject: Re: [ogl-sample] Future of the SI?
From: "Kendall Bennett" <KendallB@xxxxxxxxxxxxxxx>
Date: Thu, 27 Apr 2000 12:55:09 -0800
In-reply-to: <20000426000415.A25774@xxxxxxxxxxxxxxxxxxxx>
Organization: SciTech Software, Inc.
References: <200004231324791.SM00160@KENDALLB>; from Kendall Bennett on Sun, Apr 23, 2000 at 01:22:33PM -0800
Reply-to: ogl-sample@xxxxxxxxxxx
Sender: owner-ogl-sample@xxxxxxxxxxx
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 ;-)


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

<Prev in Thread] Current Thread [Next in Thread>