GLX_ARB_get_proc_address

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

    Complete. Approved by ARB on 12/8/1999

Version

    Last Modified Date: January 3, 2000

Number

    ARB Extension #2

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 - see the function declaration

	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 must 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.
	This should be made abundantly clear in the documentation, so
	that portable applications assume context-dependent behavior.

    * 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. Adds consistency at the cost of a much larger lookup
	mechanism.

    * 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.

    * Should the pointers returned be required to be equal to the
      addresses of the corresponding static functions (if they exist?)

	No. This may make implementation more difficult and is of little
	apparent value to applications.

    * Should the query return NULL for entry points not supported
      by the implementation, or a pointer to a function which
      generates an error?

	NULL. There is no consistent way to generate errors
	when either GL or GLX functions may be queried.

New Procedures and Functions

    void (*glXGetProcAddressARB(const GLubyte *procName))(...)

New Tokens

    None.

Additions to Chapter 2 of the OpenGL 1.2.1 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.1 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:

    3.3.12 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.

    GL function pointers returned by glXGetProcAddressARB are
    independent of the currently bound context and may be used by any
    context which supports the extension.

    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 in GL and GLX from version
	1.0 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

Conformance Testing

    Rather than testing directly, the existing tkProcInit() mechanism in
    the OpenGL 1.2 conformance tests will be modified to use
    glXGetProcAddress when it's available, so that other ARB extensions
    will fail conformance if the query does not work.

    An alternative method which directly tests the query is to perform
    an extremely simple rendering test (e.g. glClearColor/glClear) using
    GL core function pointers returned by the query.

Revision History

    * Revision 1.1 (January 3, 2000) - Final ARB-approved version.
      Specify that GL function pointers are context independent. Specify
      that all core and extension GL and GLX functions may be queried.

Implementation Support

   List of OpenGL implementations supporting the GLX_ARB_get_proc_address extension

Original File

   Original text file for the GLX_ARB_get_proc_address extension