Thomas Roell wrote:
>
> In your message of 23 March 2000 you write:
>
> > On Wed, 22 Mar 2000, Michael Gold wrote:
> >
> > > > All future Linux/OpenGL/Mesa development should use
> > > > glXGetProcAddressARB.
> > > > But in the mean time, these three items will help ensure backward
> > > > compatibility with the existing applications, both at compile
> > > > and runtime.
> > >
> > > From your description then it sounds like the scenario Steve describes is
> > > not (or less) likely to be a problem in practice. If the prototypes are
> > > defined, there will be no compile errors, and if the EXT entry points exist
> > > in the dso, there should not be link problems either. Do you agree?
> >
> > No. Mesa is only one of the OpenGL implementations for Linux - there
> > are others. Will there be similar entrypoints in the nVidia/SGI OpenGL?
> > How about XiG's implementation?
>
> We went with a pretty much the same Solution as Mesa. Our core
> libGL.so defines all entry points for extensions that are supported by
> our drivers (i.e. X-Server). gl.h therefor has all the tokens and
> function entry points declared. To be forward compatible with
> glext.h/glGetProcAddressARB(), gl.h also declares the functions
> pointers for those extensions. gl.h does NOT include glext.h, as it
> would break old applications, and would make porting from other
> platforms uneccesary difficult. glext.h include gl.h, and only adds
> the extension defines/declarations for extensions not already covered
> by gl.h. This way things are always consistent.
>
> > This is a spec for a standard - and if adding all those entrypoints
> > into every libGL.so (and updating them regularly) is to be a part of
> > the specification - then we need to write it in.
>
> This would be a very serious maintaince problem. If there is a set of
> expected base extensions that should be there for historical reasons,
> then this is ok, but if it gets to wild, it will be a problem.
>
> > The spec should also say what happens if you (illegally) call
> > one of those stubs - perhaps it should be a GL Error kind of
> > a thing - perhaps it should just silently do nothing - or
> > maybe we want to say it's "undefined" (ie you get a core
> > dump). I don't care which we say - but if we do go this
> > way, we need to say something.
> >
> > We keep talking about "legacy apps" in this context - and I'd
> > like to point out that it's NOT just older code that'll cause
> > a one-time hit that we can somehow overcome by judicious
> > placement of dummy routines into libGL.so
>
> I think that this goes back to the original reasoning why there is a
> glGetProcAddressARB() in the first place. Extension functions should
> never be used directly on a oglbase compliant system, but ALWAYS
> retrieved throu glGetProcAddressARB(). Jon also noted very early on,
> that there are a few extensions that are really considered standard,
> and are used by a lot of legacy apps, and in fact have made it already
> into the core 1.2 standard. Those should be at least there as
> functions in libGL.so, in order not to break things. The oglbase still
> doesn't really address this part.
>
> > Anyway, if all Linux OpenGL's will commit to adding those
> > entrypoints into their libGL.so's by the time oglbase
> > becomes law - then I have a much smaller objection to
> > including glext.h into gl.h
>
> The problem is portability. There are multiple libGL.so libraries out
> there, and keeping them all in sync will be impossible. This places a
> big burden on both the application developers, as well as the
> maintainers of libGL.so. Having stubs for every possible extension is
> just not really feasable.
>
> > Just out of interest, what's the objection to doing the
> > opposite and including gl.h into glext.h ? It seems to
> > me that this would be as good a solution as the reverse
> > from the point of saving our children from the terrible
> > evils of needing two headers - and yet preserve the
> > ability of existing legal OpenGL programs to work
> > unmolested.
>
> That is what we are actually doing. But more for the reason that
> glext.h needs always types from gl.h. Especially since some extensions
> are defined in gl.h.
Thomas pretty much addressed everything that I was going to say.
Let me add a bit more though. Mesa and XFree86 4.0's libGL.so has
code to generate assembly language on the fly to implement new
entrypoints. A device driver can tell libGL so generate a new
entrypoint which dispatches through a particular slot in the dispatch
table. The address of this new entrypoint is returned by glXGetProc-
AddressARB(). This was discussed in great depth a long time ago. I
don't want to re-discuss it again but wanted to remind everyone of
this capability. It allows forward compatibility of libGL.so with
new drivers and extensions.
However, this feature only works on X86 systems at the moment. In
the interest of supporting other architectures and stand-alone Mesa,
libGL.so will also have built-in entrypoints for a bunch of extensions
which neither Mesa nor any existing drivers support (yet).
I hope we're close to settling Steve's concerns. :) Again, I think he
and Thomas and I are equally concerned about compatibility issues.
-Brian
