1Name 2 3 EXT_device_base 4 5Name Strings 6 7 EGL_EXT_device_base 8 9Contributors 10 11 James Jones 12 Daniel Kartch 13 Jamie Madill 14 15Contacts 16 17 James Jones, NVIDIA (jajones 'at' nvidia.com) 18 19Status 20 21 Complete 22 23 Rewritten in terms of split functionality in EXT_dispay_device and 24 EXT_device_enumeration. 25 26Version 27 28 Version 9 - March 24th, 2015 29 30Number 31 32 EGL Extension #72 33 34Extension Type 35 36 EGL client extension 37 38Dependencies 39 40 Written against the wording of EGL 1.5. 41 42 The specifications of EGL_EXT_device_query and 43 EGL_EXT_device_enumeration are required to determine the 44 specification of this extension, although those extensions may not 45 be supported. 46 47Overview 48 49 Increasingly, EGL and its client APIs are being used in place of 50 "native" rendering APIs to implement the basic graphics 51 functionality of native windowing systems. This creates demand 52 for a method to initialize EGL displays and surfaces directly on 53 top of native GPU or device objects rather than native window 54 system objects. The mechanics of enumerating the underlying 55 native devices and constructing EGL displays and surfaces from 56 them have been solved in various platform and implementation- 57 specific ways. The EGL device family of extensions offers a 58 standardized framework for bootstrapping EGL without the use of 59 any underlying "native" APIs or functionality. 60 61 This extension defines the first step of this bootstrapping 62 process: Device enumeration. 63 64New Types 65 66 As defined by EGL_EXT_device_query. 67 68New Functions 69 70 As defined by EGL_EXT_device_query and EGL_EXT_device_enumeration. 71 72New Tokens 73 74 As defined by EGL_EXT_device_query. 75 76Add to section "3.2 Devices" 77 78 "EGL_EXT_device_base is equivalent to the combination of the 79 functionality defined by EGL_EXT_device_query and 80 EGL_EXT_device_enumeration." 81 82Issues 83 84 1. Should there be a mechanism (such as an attribute list) to 85 filter devices in eglQueryDevicesEXT()? 86 87 RESOLVED: No. This could develop too much complexity, like 88 the EGLConfig mechanism. Instead, force applications to query 89 all devices and implement any desired filtering themselves. 90 91 2. Should there be an eglSetDeviceAttribEXT()? 92 93 RESOLVED: No. Device properties are immutable. 94 95 3. Should a device file descriptor attribute be included in the 96 base specification? 97 98 RESOLVED: No. It seems like an arbitrary attribute to include 99 in the base extension. Other extensions can easily be added 100 if this or other device attributes are needed. 101 102 4. Should EGLDeviceEXT handles be opaque pointers or 32-bit 103 values? 104 105 RESOLVED: Opaque pointers. The trend seems to be to use 106 opaque pointers for object handles, and opaque pointers allow 107 more implementation flexibility than 32-bit values. 108 Additionally, the introduction of the EGLAttrib type allows 109 inclusion of pointer-sized types in attribute lists, which was 110 the only major advantage of 32-bit types. 111 112 5. Should eglQueryDisplayAttribEXT be defined as part of this 113 extension? 114 115 RESOLVED: Yes. There are no other known uses for this 116 function, so it should be defined here. If other uses are 117 found, future extension specifications can reference this 118 extension or retroactively move it to a separate extension. 119 120 6. How should bonded GPU configurations, such as SLI or Crossfire 121 be enumerated? What about other hybrid rendering solutions? 122 123 RESOLVED: Bonded GPUs should appear as one device in this API, 124 since the client APIs generally treat them as one device. 125 Further queries can be added to distinguish the lower-level 126 hardware within these bonded devices. 127 128 Hybrid GPUs, which behave independently but are switched 129 between in a manner transparent to the user, should be 130 enumerated separately. This extension is intended to be used 131 at a level of the software stack below this type of automatic 132 switching or output sharing. 133 134 7. Should this extension require all displays to have an 135 associated, queryable device handle? 136 137 RESOLVED: Yes. This allows creating new namespace containers 138 that all displays can be grouped in to and allows existing 139 applications with display-based initialization code to easily 140 add device-level functionality. Future extensions are 141 expected to expose methods to correlate EGL devices and native 142 devices, and to use devices as namespaces for future objects 143 and operations, such as cross-display EGL streams. 144 145 8. Are device handles returned by EGL valid in other processes? 146 147 RESOLVED: No. Another level of indirection is required to 148 correlate two EGL devices in separate processes. 149 150 9. Is a general display pointer query mechanism needed, or should 151 an eglGetDevice call be added to query a display's associated 152 device? 153 154 RESOLVED: A general mechanism is better. It may have other 155 uses in the future. 156 157 10. Should a new type of extension be introduced to query device- 158 specific extensions? 159 160 RESOLVED: Yes. Without this mechanism, it is likely that most 161 device extensions would require a separate mechanism to 162 determine which devices actually support them. Further, 163 requiring all device-level extensions to be listed as client 164 extensions forces them to be implemented in the EGL client 165 library, or "ICD". This is unfortunate since vendors will 166 likely wish to expose vendor-specific device extensions. 167 168 These advantages were weighed against the one known 169 disadvantage of a separate extension type: Increasing the 170 complexity of this extension and the EGL extension mechanism 171 in general. 172 173 11. Is eglQueryDeviceStringEXT necessary, or should the device 174 extension string be queried using eglQueryDeviceAttribEXT? 175 176 RESOLVED: Using a separate query seems more consistent with 177 how the current extension strings are queried. 178 179 12. Should this extension contain both device enumeration and 180 the ability to query the device backing an EGLDisplay? 181 182 RESOLVED: This extension initially included both of these 183 abilities. To allow simpler implementations to add only the 184 ability to query the device of an existing EGLDisplay, this 185 extension was split into two separate extensions: 186 187 EGL_EXT_device_query 188 EGL_EXT_device_enumeration 189 190 The presence of this extension now only indicates support 191 for both of the above extensions. 192 193Revision History: 194 195 #9 (March 24th, 2015) James Jones 196 - Split the extension into two child extensions: 197 EGL_EXT_device_query 198 EGL_EXT_device_enumeration 199 200 #8 (May 16th, 2014) James Jones 201 - Marked the extension complete. 202 - Marked all issues resolved. 203 204 #7 (April 8th, 2014) James Jones 205 - Renamed eglGetDisplayAttribEXT back to 206 eglQueryDisplayAttribEXT. 207 - Update wording based on the EGL 1.5 specification. 208 - Use EGLAttrib instead of EGLAttribEXT. 209 - Assigned values to tokens. 210 211 #6 (November 6th, 2013) James Jones 212 - Added EGL_BAD_DEVICE_EXT error code. 213 - Renamed some functions for consistency with the core spec 214 215 #5 (November 6th, 2013) James Jones 216 - Specified this is a client extension 217 - Renamed eglQueryDisplayPointerEXT eglGetDisplayAttribEXT 218 and modified it to use the new EGLAttribEXT type rather than 219 a void pointer 220 - Introduced the "device" extension type. 221 - Added eglQueryDeviceStringEXT to query device extension 222 strings 223 - Removed issues 5, 10, and 12 as they are no longer relevant 224 - Added issues 10 and 11. 225 226 #4 (May 14th, 2013) James Jones 227 - Merged in EGL_EXT_display_attributes 228 - Changed eglGetDisplayPointerEXT to eglQueryDisplayPointerEXT 229 - Remove eglGetDisplayAttribEXT since it has no known use case 230 231 #3 (April 23rd, 2013) James Jones 232 - Include EGL_NO_DEVICE_EXT 233 - Added issues 8 and 9 234 235 #2 (April 18th, 2013) James Jones 236 - Reworded issue 3 and flipped the resolution 237 - Added issues 5, 6, and 7 238 - Filled in the actual spec language modifications 239 - Renamed from EGL_EXT_device to EGL_EXT_device_base 240 - Fixed some typos 241 242 #1 (April 16th, 2013) James Jones 243 - Initial Draft 244