Jon Leech wrote: > > On Wed, Sep 08, 1999 at 10:25:08PM -0400, Brian Paul wrote: > > Issues > > > > * Is this extension properly named? > > I'm semi-convinced this should actually sit in its own namespace, > and then initially we put it in GLX by analogy to the WGL equivalent. As I was implementing it I found that it would be cleaner if it were a GLX function. I had to add a device driver hook in Mesa so that core Mesa could query function pointers from device drivers (such as the X/Mesa driver inside Mesa's GLX interface). However, if we call it glXGetProcAddressEXT, consider the problem for GLUT-based programs. Clearly, a GLUT-based program shouldn't be making GLX calls. I guess the solution to that is for GLUT to offer a glutGetProcAddress() function which wraps either glXGetProc- AddressEXT or wglGetProcAddress. I think this would be the first GLUT function to return a pointer. Jon, what exactly do you have in mind for "its own namespace"? > > * Is void * the appropriate return type? > > void (*)(...) seems more appropriate now. Or maybe a GL typedef > (glFunctionPointerEXT?) Either would be fine with me. Anyone else? > > * 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 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. > > 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. 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. > 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. -Brian
