Names
KHR_get_all_proc_addresses
KHR_client_get_all_proc_addresses
Name Strings
EGL_KHR_get_all_proc_addresses
EGL_KHR_client_get_all_proc_addresses
Contributors
Jon Leech
Marcus Lorentzon
Robert Palmer
Acorn Pooley
Greg Prisament
Chad Versace
Contacts
James Jones, NVIDIA (jajones 'at' nvidia.com)
Notice
Copyright (c) 2013 The Khronos Group Inc. Copyright terms at
http://www.khronos.org/registry/speccopyright.html
Status
Complete. Approved by the EGL Working Group on April 3, 2013.
Ratified by the Khronos Board of Promoters on July 19, 2013.
Version
Version 3 - July 31, 2013
Number
EGL Extension #61
Extension Types
EGL_KHR_get_all_proc_addresses is an EGL display extension
EGL_KHR_client_get_all_proc_addresses is an EGL client extension
Dependencies
EGL 1.2 is required.
This extension is written based on the wording of the EGL 1.4
specification.
Interacts with EGL_EXT_client_extensions.
Overview
eglGetProcAddress is currently defined to not support the querying
of non-extension EGL or client API functions. Non-extension
functions are expected to be exposed as library symbols that can
be resolved statically at link time, or dynamically at run time
using OS-specific runtime linking mechanisms.
With the addition of OpenGL and OpenGL ES 3 support to EGL, the
definition of a non-extension function becomes less clear. It is
common for one OpenGL library to implement many versions of
OpenGL. The suggested library name for OpenGL ES 3 is the same as
that of OpenGL ES 2. If OpenGL ES 3 applications linked
statically to OpenGL ES 3 functions are run on a system with only
OpenGL ES 2 support, they may fail to load. Similar problems
would be encountered by an application linking statically to
various OpenGL functions.
To avoid requiring applications to fall back to OS-specific
dynamic linking mechanisms, this extension drops the requirement
that eglGetProcAddress return only non-extension functions. If
the extension string is present, applications can query all EGL
and client API functions using eglGetProcAddress.
To allow users to query this extension before initializing a display, and
to also allow vendors to ship this extension without
EGL_EXT_client_extensions, two names are assigned to this extension: one
a display extension and the other a client extension. Identical
functionality is exposed by each name, but users query each name using
different methods. Users query EGL_KHR_get_all_proc_addresses in the
usual way; that is, by calling eglQueryString(dpy, EGL_EXTENSIONS) on an
initialized display. To query EGL_KHR_client_get_all_proc_addresses,
users must use a different method which is described below in the section
concerning EGL_EXT_client_extensions.
New Types
None
New functions
None
New Tokens
None
Rename section "3.10 Obtaining Extension Function Pointers" to "3.10
Obtaining Function Pointers", and replace its content with the
following:
"The client API and EGL extensions and versions which are available to a
client may vary at runtime, depending on factors such as the rendering
path being used (hardware or software), resources available to the
implementation, or updated device drivers. Therefore, the address of
functions may be queried at runtime. The function
void (*eglGetProcAddress(const char *procname))(void);
returns the address of the function named by <procName>. <procName> must
be a NULL-terminated string. The pointer returned should be cast to a
function pointer matching the function's definition in the corresponding
API or extension specification. A return value of NULL indicates that
the specified function does not exist for the implementation.
A non-NULL return value for eglGetProcAddress does not guarantee that a
function is actually supported at runtime. The client must also make a
corresponding query, such as glGetString(GL_EXTENSIONS) for OpenGL and
OpenGL ES extensions; vgGetString(VG_EXTENSIONS) for OpenVG extensions;
eglQueryString(dpy, EGL_EXTENSIONS) for EGL extensions; or query the
corresponding API's version for non-extension functions, to determine if
a function is supported by a particular client API context or display.
Client API function pointers returned by eglGetProcAddress are
independent of the display and the currently bound client API context,
and may be used by any client API context which supports the function.
eglGetProcAddress may be queried for all EGL and client API extension
and non-extension functions supported by the implementation (whether
those functions are supported by the current client API context or not).
For functions that are queryable with eglGetProcAddress, implementations
may also choose to export those functions statically from the object
libraries implementing them. However, portable clients cannot rely on
this behavior."
Interactions with EGL_EXT_client_extensions
The EGL specification describes the behavior of eglGetProcAddress as
independent of any display. Therefore, this extension's functionality
falls under the classification 'client extension' rather than 'display
extension'. Accordingly, users may wish to query this extension before
initializing a display.
If the EGL_EXT_client_extensions is supported, then users can query this
extension by checking for the name EGL_KHR_client_get_all_proc_addresses
in the extension string of EGL_NO_DISPLAY.
The EGL implementation must expose the name
EGL_KHR_client_get_all_proc_addresses if and only if it exposes
EGL_KHR_get_all_proc_addresses and supports EGL_EXT_client_extensions.
This requirement eliminates the problematic situation where, if an EGL
implementation exposed only one name, then an EGL client would fail to
detect the extension if it queried only the other name.
Despite having two names assigned to this extension, the restrictions
described in EGL_EXT_client_extensions still apply. As
EGL_KHR_client_get_all_proc_addresses is defined as a client extension,
its name can appear only in the extension string of EGL_NO_DISPLAY and
not in the extension string of any valid display. The converse applies
to EGL_KHR_get_all_proc_addresses, as it is defined as a display
extension.
Issues
1. What should this spec be called?
PROPOSED: KHR_get_all_proc_addresses
2. Should this extension be classified as a client extension, as defined
by EGL_EXT_client_extensions?
DISCUSSION: Yes and no.
Yes, because this extension exposes functionality that is solely
a property of the EGL library itself, independent of any display.
Such functionality falls under the classification of 'client
extension'.
No, because classifying it as a client extension would create
a dependency on EGL_EXT_client_extensions, and there exists no
precedent for a KHR extension that depends on an EXT extension.
RESOLUTION: Expose this extension under two names, one a client
extension and the other a display extension.
Revision History
#3 (July 31, 2013) Chad Versace
- Assign additional name, EGL_KHR_client_get_all_proc_addresses.
- Add section "Extension Types", section "Interactions with
EGL_EXT_client_extensions", and issue #2.
#2 (March 6, 2013) Jon Leech
- Bring into sync with latest EGL 1.4 spec update and simplify
language describing which functions may be queried. Minor
formatting changes for greater consistency with other KHR
extension specs.
#1 (February 4, 2013) James Jones
- Initial draft
