ogl-sample
[Top] [All Lists]

[ogl-sample] Driver interfaces

To: ogl-sample@xxxxxxxxxxx
Subject: [ogl-sample] Driver interfaces
From: Jon Leech <ljp@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 27 Apr 2000 13:12:30 -0700
In-reply-to: <200004271257215.SM00160@KENDALLB>; from Kendall Bennett on Thu, Apr 27, 2000 at 12:55:09PM -0800
References: <200004231324791.SM00160@KENDALLB>; <20000426000415.A25774@xxxxxxxxxxxxxxxxxxxx> <200004271257215.SM00160@KENDALLB>
Reply-to: ogl-sample@xxxxxxxxxxx
Sender: owner-ogl-sample@xxxxxxxxxxx
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

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