In your message of 8 September 1999 you write:
> > * Should GetProcAddressEXT allow querying of itself?
> >
> > * There's a recursion problem with this feature. The purpose of
> > GetProcAddressEXT is to return pointers to extension functions
> > and GetProcAddressEXT is itself such a function! This presents
> > a puzzle to the application developer.
>
> 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 would strongly opt for having the few entry points that the OpenGL
1.1 SI added there, as well as the texturing extensions to OpenGL
1.0. Our experiance with customers who are proting down from other
platforms has been that those are considered very core.
Explicitely the entry points are:
glAreTexturesResidentEXT
glBindTextureEXT
glCopyTexImage1DEXT
glCopyTexImage2DEXT
glCopyTexSubImage1DEXT
glCopyTexSubImage2DEXT
glDeleteTexturesEXT
glGenTexturesEXT
glIsTextureEXT
glPrioritizeTexturesEXT
glTexSubImage1DEXT
glTexSubImage2DEXT
glBlendColorEXT
glBlendEquationEXT
Also I would love to see the ARB_multitexture API entry points see to
be available as directly callable functions, as those are VERY widely
used.
glActiveTextureARB
glClientActiveTextureARB
glMultiTexCoord1dARB
glMultiTexCoord1dvARB
glMultiTexCoord1fARB
glMultiTexCoord1fvARB
glMultiTexCoord1iARB
glMultiTexCoord1ivARB
glMultiTexCoord1sARB
glMultiTexCoord1svARB
glMultiTexCoord2dARB
glMultiTexCoord2dvARB
glMultiTexCoord2fARB
glMultiTexCoord2fvARB
glMultiTexCoord2iARB
glMultiTexCoord2ivARB
glMultiTexCoord2sARB
glMultiTexCoord2svARB
glMultiTexCoord3dARB
glMultiTexCoord3dvARB
glMultiTexCoord3fARB
glMultiTexCoord3fvARB
glMultiTexCoord3iARB
glMultiTexCoord3ivARB
glMultiTexCoord3sARB
glMultiTexCoord3svARB
glMultiTexCoord4dARB
glMultiTexCoord4dvARB
glMultiTexCoord4fARB
glMultiTexCoord4fvARB
glMultiTexCoord4iARB
glMultiTexCoord4ivARB
glMultiTexCoord4sARB
glMultiTexCoord4svARB
> > Additions to Chapter 6 of the OpenGL 1.2 Specification (State and State
> > Requests)
> >
> > Add a new section numbered 6.1.13:
> >
> > 6.1.13 Obtaining Extension Function Pointers
> >
> > The GL extensions which are available to a client application can
> > only be determined at runtime. Therefore, the address of extension
> > functions should be queried at runtime.
>
> 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.
All extension functions should be ALWAYS retrieveable by
GetProcAddressEXT(). It should be also clear that with the exception
of a base set of directly callable extension functions this is the
only portable way for access the functions.
I would also love to have a stetement added that if GetProcAccessEXT()
returns a non-NULL pointer to an extension function, that this does
not imply that the extension is usable. The presence of an extension
should be determinded by
glGetString()/glXQueryExtensionsString(). Rationale is that a GLX
based libGL.so has to have the encoding/decoding part for the
extension, while the X-Server side 3D pipeline might not support the
extension.
> 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.
Please let's avoid this. It would be intresting to know as to why
people are using this approach.
> > 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.
What is the rationale for this constraint ?
Would this imply what for every context that is created a seperate
pointer had to be queried ?
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
