Name
EXT_device_base
Name Strings
EGL_EXT_device_base
Contributors
James Jones
Daniel Kartch
Jamie Madill
Contacts
James Jones, NVIDIA (jajones 'at' nvidia.com)
Status
Complete
Rewritten in terms of split functionality in EXT_dispay_device and
EXT_device_enumeration.
Version
Version 9 - March 24th, 2015
Number
EGL Extension #72
Extension Type
EGL client extension
Dependencies
Written against the wording of EGL 1.5.
The specifications of EGL_EXT_device_query and
EGL_EXT_device_enumeration are required to determine the
specification of this extension, although those extensions may not
be supported.
Overview
Increasingly, EGL and its client APIs are being used in place of
"native" rendering APIs to implement the basic graphics
functionality of native windowing systems. This creates demand
for a method to initialize EGL displays and surfaces directly on
top of native GPU or device objects rather than native window
system objects. The mechanics of enumerating the underlying
native devices and constructing EGL displays and surfaces from
them have been solved in various platform and implementation-
specific ways. The EGL device family of extensions offers a
standardized framework for bootstrapping EGL without the use of
any underlying "native" APIs or functionality.
This extension defines the first step of this bootstrapping
process: Device enumeration.
New Types
As defined by EGL_EXT_device_query.
New Functions
As defined by EGL_EXT_device_query and EGL_EXT_device_enumeration.
New Tokens
As defined by EGL_EXT_device_query.
Add to section "3.2 Devices"
"EGL_EXT_device_base is equivalent to the combination of the
functionality defined by EGL_EXT_device_query and
EGL_EXT_device_enumeration."
Issues
1. Should there be a mechanism (such as an attribute list) to
filter devices in eglQueryDevicesEXT()?
RESOLVED: No. This could develop too much complexity, like
the EGLConfig mechanism. Instead, force applications to query
all devices and implement any desired filtering themselves.
2. Should there be an eglSetDeviceAttribEXT()?
RESOLVED: No. Device properties are immutable.
3. Should a device file descriptor attribute be included in the
base specification?
RESOLVED: No. It seems like an arbitrary attribute to include
in the base extension. Other extensions can easily be added
if this or other device attributes are needed.
4. Should EGLDeviceEXT handles be opaque pointers or 32-bit
values?
RESOLVED: Opaque pointers. The trend seems to be to use
opaque pointers for object handles, and opaque pointers allow
more implementation flexibility than 32-bit values.
Additionally, the introduction of the EGLAttrib type allows
inclusion of pointer-sized types in attribute lists, which was
the only major advantage of 32-bit types.
5. Should eglQueryDisplayAttribEXT be defined as part of this
extension?
RESOLVED: Yes. There are no other known uses for this
function, so it should be defined here. If other uses are
found, future extension specifications can reference this
extension or retroactively move it to a separate extension.
6. How should bonded GPU configurations, such as SLI or Crossfire
be enumerated? What about other hybrid rendering solutions?
RESOLVED: Bonded GPUs should appear as one device in this API,
since the client APIs generally treat them as one device.
Further queries can be added to distinguish the lower-level
hardware within these bonded devices.
Hybrid GPUs, which behave independently but are switched
between in a manner transparent to the user, should be
enumerated separately. This extension is intended to be used
at a level of the software stack below this type of automatic
switching or output sharing.
7. Should this extension require all displays to have an
associated, queryable device handle?
RESOLVED: Yes. This allows creating new namespace containers
that all displays can be grouped in to and allows existing
applications with display-based initialization code to easily
add device-level functionality. Future extensions are
expected to expose methods to correlate EGL devices and native
devices, and to use devices as namespaces for future objects
and operations, such as cross-display EGL streams.
8. Are device handles returned by EGL valid in other processes?
RESOLVED: No. Another level of indirection is required to
correlate two EGL devices in separate processes.
9. Is a general display pointer query mechanism needed, or should
an eglGetDevice call be added to query a display's associated
device?
RESOLVED: A general mechanism is better. It may have other
uses in the future.
10. Should a new type of extension be introduced to query device-
specific extensions?
RESOLVED: Yes. Without this mechanism, it is likely that most
device extensions would require a separate mechanism to
determine which devices actually support them. Further,
requiring all device-level extensions to be listed as client
extensions forces them to be implemented in the EGL client
library, or "ICD". This is unfortunate since vendors will
likely wish to expose vendor-specific device extensions.
These advantages were weighed against the one known
disadvantage of a separate extension type: Increasing the
complexity of this extension and the EGL extension mechanism
in general.
11. Is eglQueryDeviceStringEXT necessary, or should the device
extension string be queried using eglQueryDeviceAttribEXT?
RESOLVED: Using a separate query seems more consistent with
how the current extension strings are queried.
12. Should this extension contain both device enumeration and
the ability to query the device backing an EGLDisplay?
RESOLVED: This extension initially included both of these
abilities. To allow simpler implementations to add only the
ability to query the device of an existing EGLDisplay, this
extension was split into two separate extensions:
EGL_EXT_device_query
EGL_EXT_device_enumeration
The presence of this extension now only indicates support
for both of the above extensions.
Revision History:
#9 (March 24th, 2015) James Jones
- Split the extension into two child extensions:
EGL_EXT_device_query
EGL_EXT_device_enumeration
#8 (May 16th, 2014) James Jones
- Marked the extension complete.
- Marked all issues resolved.
#7 (April 8th, 2014) James Jones
- Renamed eglGetDisplayAttribEXT back to
eglQueryDisplayAttribEXT.
- Update wording based on the EGL 1.5 specification.
- Use EGLAttrib instead of EGLAttribEXT.
- Assigned values to tokens.
#6 (November 6th, 2013) James Jones
- Added EGL_BAD_DEVICE_EXT error code.
- Renamed some functions for consistency with the core spec
#5 (November 6th, 2013) James Jones
- Specified this is a client extension
- Renamed eglQueryDisplayPointerEXT eglGetDisplayAttribEXT
and modified it to use the new EGLAttribEXT type rather than
a void pointer
- Introduced the "device" extension type.
- Added eglQueryDeviceStringEXT to query device extension
strings
- Removed issues 5, 10, and 12 as they are no longer relevant
- Added issues 10 and 11.
#4 (May 14th, 2013) James Jones
- Merged in EGL_EXT_display_attributes
- Changed eglGetDisplayPointerEXT to eglQueryDisplayPointerEXT
- Remove eglGetDisplayAttribEXT since it has no known use case
#3 (April 23rd, 2013) James Jones
- Include EGL_NO_DEVICE_EXT
- Added issues 8 and 9
#2 (April 18th, 2013) James Jones
- Reworded issue 3 and flipped the resolution
- Added issues 5, 6, and 7
- Filled in the actual spec language modifications
- Renamed from EGL_EXT_device to EGL_EXT_device_base
- Fixed some typos
#1 (April 16th, 2013) James Jones
- Initial Draft