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