| > > Well,
| > >
| > > what about the point that there are different vendors out there
| > > supplying a libGL, that for some reason uses a totally different
| > > dispatch mechanism ?
| >
| > Are you speaking of driver writers here? If so, what I've proposed won't
| > affect them in any way. If you're not talking about driver writers, I
| > don't understand your point. Aren't we trying to create a standard here
| > so that there _won't_ be various flavors of libGL floating around?
|
| NO!
|
| There are commercial OpenGL ports for Linux out there - and we
| should not shut them out. Mesa is certainly the most important
| and most prevalent OpenGL for Linux (although it's technically
| not even OpenGL)...but the commercial OpenGL's are important too.
|
| The point of this standard is to ensure that a program compiled
| for Mesa will run if the user happens to have installed a
| commercial OpenGL - and vice-versa.
|
| If Linux takes off on the desktop (as we all clearly expect - or
| we wouldn't be here), then we can expect some of the hardware
| vendors to want to produce their own OpenGL implementations rather
| than use Linux and reveal their precious secrets by using Mesa.
| I predict this will happen more and more as hardware T&L comes
| on stream over the next year or two.
|
| We NEED for those commercial OpenGL's to play together.
|
| That's why we are here.
Well, then we were done several weeks ago since the implementations
details are just that, implementation details, and continuing such
a discussion is adding zero information. That said, there are
a bunch of us that are interested in having an interoperable dispatch
infrastructure so that we can concievably support multiple heterogeoneous
accelerators from different vendors under, say, XFree86. Perhaps we
should move such a discussion of details to achieve such interoperability
to another forum rather than clutter linux-base since it has nothing to do
with app compatability and everything to do with vendor integration.
-db
