ajax at nwnk.net
Tue Feb 22 12:45:16 PST 2005
On Tuesday 22 February 2005 15:20, Jon Smirl wrote:
> On Tue, 22 Feb 2005 15:15:37 -0500, Adam Jackson <ajax at nwnk.net> wrote:
> > On Tuesday 22 February 2005 15:08, Jon Smirl wrote:
> > > On Tue, 22 Feb 2005 11:16:47 -0700, Brian Paul
> > > <brian.paul at tungstengraphics.com> wrote:
> > >
> > > Are you aware of this?
> > >
> > > http://sourceforge.net/projects/dogless
> > > Can also wrap on the standard OpenGL impl with ES simulation.
> > Both dogless and klimt are GPL-licensed so they're not really suitable.
> Are they useful enough to ask for a license change?
I don't think so. Really all we're aiming for here, now, is the EGL API, and
Brian and I have both pretty much done that already (though in different
directions). We already have a world-class GL engine in Mesa.
Klimt simply doesn't aim as high. There are several features missing from
Klimt that would be total showstoppers for what we're trying to use GL for -
alpha buffer, glReadPixels, multitexturing, stencil tests, clip planes... So
while it provides something resembling the EGL API it lacks features we want.
Dogless is win32 only, it seems. And it's actually an inversion of the model
we're thinking about. Dogless appears to translate WGL to EGL, so you can
have some tiny EGL stack and then run Quake on it (where presumably this
stack mirrors the stack you're going to put on your embedded device). So it
doesn't even provide the EGL API to begin with.
There's in my mind three pieces of the OpenGL|ES stack here:
- EGL, the API that binds you to your native windowing system (or in our case,
- The GL engine
- The various OES_* extensions
#1 turns out to be pretty easy to add. #2 we already have. #3 isn't really
interesting for desktop hardware but is also pretty easy to add should
someone want to invest the effort (most of them are just adding support for
various small data types, which we can upconvert transparently before handing
to the existing Mesa engine).
So, since we pretty much have the API, and since the API is the new piece
we're trying to leverage, I don't really see the point in chasing after
license changes for software that isn't capable of what we want to use GL
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg