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