On Thu, Nov 04, 1999 at 03:19:38PM -0800, Michael I Gold wrote:
> On the other hand Jon raises a valid point which was lost on me until I
> studies his example more closely. If we always return a valid pointer, the
> application could be query "foo" and "yo-mama" with no less success than
> querying "glActiveTextureARB".
Bingo! Just how large *is* this dynamic dispatch table allowed to
get?
> The useful diagnostic here is whether or
> not the app has correctly spelled the name of the entry point. If he has
> not, and instead queries "glActiveTextureARV", are we doing him a favor by
> returning a valid pointer? I would argue "no".
>
> I believe the best compromise would be to always return a valid pointer for
> any arbitrary string the app queries, but if a given implementation does
> not support the entry point (even if other drivers on the system do), let
> it crash in the dispatch (he says, in his typically callous manner). That
> serves both purposes, and the app programmer will know right away that he
> did something wrong.
I could live with that. If someone has a *specifiable* and
*meaningful* way of generating an error, I could go for that too - but I
cannot see how to, and all people have been saying is "generate an
error" without providing details. So what type of error should calling
through the "yo-mama" function pointer generate? The answer might be
easier if had separate queries for GLX and GL functions, but we don't
now...
Here's a new version of the spec revised to remove GLU queries and
adding the following two issues:
122a128,137
> * Can core GL 1.0 / GLX 1.0 features be queried?
>
> TBD. Adds consistency at the cost of a much larger lookup
> mechanism.
>
> * Should the pointers returned be required to be equal to the
> addresses of the corresponding static functions (if they exist?)
>
> TBD. This may be unreasonable to mandate.
Jon
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
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?
GLX: Yes. GLU: No. 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. Since GLU is an client library using
GL, GLU extensions are unlikely to need to be dynamically
queryable. This capability could be added in a future extension.
* GLU library may not be loaded at runtime, making GLU queries fail
No longer relevant, since GLU functions cannot be queries now.
The previous resolution was:
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 and GLX 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 and GLX 1.0 be queryable?
Yes.
* 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.
* Can core GL 1.0 / GLX 1.0 features be queried?
TBD. Adds consistency at the cost of a much larger lookup
mechanism.
* Should the pointers returned be required to be equal to the
addresses of the corresponding static functions (if they exist?)
TBD. This may be unreasonable to mandate.
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 and GLX 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) or
glXQueryExtensionsString 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 or GLX 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 and GLX 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 and GLX
after version 1.0 and up to and including the versions of those
specifications supported by the implementation, as determined by
glGetString(GL_VERSION) and glXQueryVersion 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.
* Revision 1.6a - (4 November 1999, Jon Leech)
- Once again remove ability to query GLU functions.
- Add pointer-equality and core 1.0 feature queryability to issues
list.
