I've revised the extension specification (attached) following our
straw poll to make it a GLX function returning context-independent
pointers. As a logical consequence the function should return any of GL,
GLX, or GLU functions.
Hopefully, the nitpicky details of moving it from GL to GLX have
been taken care of. If there are any actual bugs in the proposal, please
identify them ASAP. This extension *will* be presented to the ARB on
Monday, November 8th.
Jon Leech
SGI
Name
ARB_get_proc_address
Name Strings
GLX_ARB_get_proc_address
Contact
Brian Paul (brian_paul 'at' mesa3d.org)
Jon Leech (ljp 'at' sgi.com)
Status
XXX - Not complete yet!!!
Version
$Id: GL_ARB_get_proc_address.spec,v 1.6$
XXX not checked in yet
Number
???
Dependencies
The extension is written against the GLX 1.3 Specification.
May be implemented in any version of GLX and OpenGL.
Overview
This extension adds a function to return the address of GLX, GLU,
and GL extension functions, given the function name. This is
necessary with (for example) heterogenous implementations where
hardware drivers may implement extension functions not known to the
link library; a similar situation on Windows implementations
resulted in the wglGetProcAddress function.
IP Status
No IP is believed to be involved (dynamic querying of library entry
points is supported in all modern operating systems).
Issues
* Is this extension properly named?
Yes. If it does not achieve ARB approval, it will be implemented
as an EXT.
* Should a typedef be used for the return type?
typedef void (*GLfunction)();
extern GLfunction glXGetProcAddressARB(const GLubyte *procName);
Not needed. The following works:
void (*glXGetProcAddressARB(const GLubyte *procName)();
* Should GetProcAddressARB allow querying of itself?
Yes, for sake of completeness.
* There's a recursion problem with this feature. The purpose of
GetProcAddressARB is to return pointers to extension functions and
GetProcAddressARB is itself such a function! This presents a
puzzle to the application developer.
Implementations should always export the glXGetProcAddressARB
entry point statically.
* Should extension functions in GLU and GLX be queryable through
this extension?
Yes. Because the pointers returned are context-independent, the
query was lifted from GL (in which all behavior is necessarily
context-dependent) into GLX, where context management occurs.
* GLU library may not be loaded at runtime, making GLU queries fail
True. However, the GL/GLX/GLU specifications say nothing about
"libraries" and link/runtime issues in any event, and the same
criticism might be applied to GL or GLX queries depending on how
the development and runtime tools on a particular platform
operate. Requiring a link against a "GLU library" in this case
should be in the release notes for a platform.
* Should corresponding functions exist in the window-system specific
layer on non-GLX implementations?
Yes. wglGetProcAddress already exists for Microsoft Windows, and
Apple has stated they will support aglGetProcAddress.
Unfortunately, there is an unavoidable inconsistency with
wglGetProcAddress, which returns context-dependent pointers.
* Should the core functions added to GL, GLX, and GLU since their
1.0 versions be queryable?
Yes. This will allow maximum portability of applications across
OpenGL 1.1 and 1.2 library implementations.
* Should the core functions in GL 1.0, GLX 1.0, and GLU 1.0
be queryable?
TBD, but probably not.
* Are function pointers context-independent?
Yes. The pointer to an extension function can be used with any
context which supports the extension. Concern was expressed that
function dispatch for context-independent pointers would incur
overheads compared to context-dependent pointers.
The working group has proposed several implementation strategies
which would make this overhead negligible to nonexistent, and
the benefits of lifting the context/pointer management burden
from applications were considerable. The implementation
strategies are moderately complex and reach down all the way to
the toplevel dispatch mechanism used by drivers.
New Procedures and Functions
void (*glXGetProcAddressARB(const GLubyte *procName))()
New Tokens
None.
Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation)
None
Additions to Chapter 3 of the OpenGL 1.2.1 Specification (Rasterization)
None
Additions to Chapter 4 of the OpenGL 1.2.1 Specification (Per-Fragment
Operations and the Frame Buffer)
None
Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special
Functions)
None
Additions to Chapter 6 of the OpenGL 1.2 Specification (State and State
Requests)
None
Additions to Appendix A of the OpenGL 1.2.1 Specification (Invariance)
None
Additions to the GLX Specification
Add a new section numbered 3.3.12:
6.1.13 Obtaining Extension Function Pointers
The GL, GLX, and GLU extensions which are available to a client
application may vary at runtime. Therefore, the address of extension
functions may be queried at runtime. The function
void (*glXGetProcAddressARB(const ubyte *procName)();
returns the address of the extension function named by procName. The
pointer returned should be cast to a function pointer type matching
the extension function's definition in that extension specification.
A return value of NULL indicates that the specified function does
not exist for the implementation.
A non-NULL return value for glXGetProcAddressARB does not guarantee
that an extension function is actually supported at runtime. The
client must must also query glGetString(GL_EXTENSIONS),
glXQueryExtensionsString, or gluGetString(GLU_EXTENSIONS) to
determine if an extension is supported by a particular context.
The function pointer returned by glXGetProcAddressARB is independent
of the currently bound context and may be used by any context which
supports the extension. If the function entrypoint is also
accessible by the GL, GLX, or GLU implementation without the query,
it will always be true that
glXGetProcAddressARB(<function>) = void (*)()&<function>
For example:
glXGetProcAddressARB("glActiveTextureARB") = &glActiveTextureARB
glXGetProcAddressARB may be queried for all of the following functions:
- All GL, GLX, and GLU extension functions supported by the
implementation (whether those extensions are supported by the
current context or not).
- All core (non-extension) functions added to GL, GLX, and GLU
after version 1.0 and up to and including the versions of those
specifications supported by the implementation, as determined by
glGetString(GL_VERSION), glXQueryVersion, and
gluGetString(GLU_VERSION) queries.
GLX Protocol
None
Errors
None
New State
None
Revision History
* Revision 1.1 - initial draft (8 Sep 1999)
* Revision 1.2 - (9 Sep 1999)
- don't allow querying of GLU, GLX, WGL functions
- changed return type to void (*)()
- allow querying of all core functions except those defined since
version 1.0
- clarification of glXGetProcAddressARB behavior with respect to
GL contexts
- updated the Issues section
* Revision 1.3 - (16 Sep 1999)
- clarification of the return type issue
* Revision 1.4 - (13 Oct 1999)
- function pointers are now context independent and equivalent to
the address of the function if it's exported by the GL library.
* Revision 1.5 - (13 Oct 1999)
- calling glXGetProcAddressARB between Begin/End may or may not
generate an error.
* Revision 1.6 - (3 November 1999, Jon Leech)
- Revise from a GL to a GLX extension. Add ability to query GLU
and GLX functions as well as GL.
- Removed INVALID_OPERATION error between Begin/End, since this is
now a GLX function.
