Message-ID: <20000427131230.A31867@oddhack.engr.sgi.com>
Date:   Thu, 27 Apr 2000 13:12:30 -0700
From:   Jon Leech <ljp@oddhack.engr.sgi.com>
To:     ogl-sample@oss.sgi.com
Subject: [ogl-sample] Driver interfaces
References: <200004231324791.SM00160@KENDALLB>; <20000426000415.A25774@oddhack.engr.sgi.com> <200004271257215.SM00160@KENDALLB>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <200004271257215.SM00160@KENDALLB>; from Kendall Bennett on Thu, Apr 27, 2000 at 12:55:09PM -0800
Sender: owner-ogl-sample@oss.sgi.com
Precedence: bulk
Reply-To: ogl-sample@oss.sgi.com

On Thu, Apr 27, 2000 at 12:55:09PM -0800, Kendall Bennett 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.

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

> 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 Sci Tech's Inertia/Nucleus driver
architecture? Where does that stand? Maybe it could be used as a
starting point.

    Jon Leech
    SGI