[Top] [All Lists]

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

To: ogl-sample@xxxxxxxxxxx
Subject: Re: [ogl-sample] Future of the SI?
From: Jon Leech <ljp@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 26 Apr 2000 00:04:15 -0700
In-reply-to: <200004231324791.SM00160@KENDALLB>; from Kendall Bennett on Sun, Apr 23, 2000 at 01:22:33PM -0800
References: <200004050727.AAA19386@xxxxxxxxxxxxxxxxxxxx> <200004231324791.SM00160@KENDALLB>
Reply-to: ogl-sample@xxxxxxxxxxx
Sender: owner-ogl-sample@xxxxxxxxxxx
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 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.

    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

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

    Jon Leech

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