In your message of 9 September 1999 you write:
> > GetProcAddressEXT must be exported from the libGL described by the
> > standard. The only extensions which *have* to be queried for in this
> > fashion are those added to a loadable driver module after the base libGL
> > it's loaded by is shipped. Exactly how we draw the line is unclear. In
> > the Windows world, only a handful of extensions are supplied in
> > OPENGL32.DLL, and everything else needs to be queried.
>
> I was thinking that _any_ extension function should be queried in
> this manner. The Mesa libGL.so might export extensions not offered
> by Xi's or Metrolinks' OpenGL.
> It would be confusing to app developers if some extensions had to
> be queried by GetProcAddressEXT() but not others.
Yes and no. New applications should use GetProcAddressEXT() for all
extensions. However the set of functions defined by OpenGL 1.2.1
(which includes ARB_multitexture, and some functions which were
previously extensions) should be available directly. Rationale is that
there are quite a few folks out there porting apps from other UNIXes
to LINUX. The fewer changes they have to make, the easier it will be
for them. A customer of ours for example has some very clean code, but
occasionally mixed up the texture_object extension with some clean
OpenGL 1.1 code. In order to avoid headaches there I would strongly
recommend to a OpenGL 1.1 / 1.2 based library to include those old API
entries as extensions, which are directly callable.
> > We need to be crystal clear on exactly which GL (and GLX) functions
> > can be queried, or implementations will make bad choices. An easy way to
> > lock in apps might be for an OpenGL implementation to expose a critical
> > extension in libGL but *not* via the query; an app calling this
> > extension directly would not run on another implementation exporting it
> > only dynamically. Instead it would fail catastrophically when calling
> > the unresolved entry point, which could then be blamed on the driver
> > although the driver would be doing exactly what it should. Both ISVs and
> > GL implementors will need to be sensitive to this.
>
> Any extension functions I add to Mesa will be accessible both by
> traditional means and by GetProcAddressEXT(). I think it's fair to
> require all OpenGL vendors to do this.
Agreed. Makes sence. I would also recommed that there is some way for
an application to link against a library that does not export those
extensions directly, in order to catch the little programmer
oversights of illegal direct call entires.
> > Also, an emerging use of wglGetProcAddress() is to return pointers
> > to OpenGL 1.2 core functions. While this exact scenario is unlikely to
> > arise on Linux, we should still be very clear up front about whether
> > non-EXT functions can be queried.
>
> I vote that only true extension (non core) functions be returned.
> This includes the ARB multitexture functions in 1.2.1.
>
>
> > > The function
> > > void *GetProcAddressEXT(const ubyte *procName);
> > > returns the address of the extension function named by procName.
> > > NULL is returned if the named function is not available.
> > >
> > > The pointer returned by GetProcAddressEXT should be cast to a
> > > function type which matches the extension function's definition.
> > >
> > > Functions which are extensions to the GL window system interface
> > > (such as GLX and WGL) are also obtainable with GetProcAddressEXT.
> >
> > Also note that the returned pointer is only valid when the current
> > context is the same as the context to which the GL was connected when
> > the pointer was obtained.
>
> I'll add this clarification. I'll post an updated draft later today
> with any other changes that come along.
A combined comment to the upper statements. I feel that the
multitexture API entries are to performance sensitive to go throu yet
another level of indirection. First there is a pointer lookup, and
then you have to go throu some internal dispatch table based upon the
context you are using. On the other hand, if glXGetProcAddressEXT()
returns a pointer relative to the current context, then it could
return a more direct pointer (like the one in the internal dispatch
table). In this case, then retrieving pointers for all API entries via
glXGetProcAddressEXT() makes sence, as it allows to reduce the number
of indirections to execture a simple glVertex3f().
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
