Solo Xgl..

[Adam Jackson]

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,
  provides it)
- 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 
for.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050222/270fa62a/attachment.pgp>