1Name 2 3 EXT_device_openwf 4 EXT_output_openwf 5 6Name Strings 7 8 EGL_EXT_device_openwf 9 EGL_EXT_output_openwf 10 11Contributors 12 13 Daniel Kartch 14 James Jones 15 Christopher James Halse Rogers 16 17Contacts 18 19 Daniel Kartch, NVIDIA (dkartch 'at' nvidia.com) 20 21Status 22 23 Complete 24 25Version 26 27 Version 5 - January 21, 2016 28 29Number 30 31 EGL Extension #80 32 33Extension Type 34 35 EGL device extension for EGL_EXT_device_openwf 36 37 EGL display extension for EGL_EXT_output_openwf 38 39Dependencies 40 41 EGL_EXT_device_openwf requires EGL_EXT_device_base. 42 43 EGL_EXT_output_openwf requires EGL_EXT_output_base. 44 45 Both require OpenWF Display 46 47 EGL_EXT_device_openwf interacts with EGL_EXT_platform_device 48 49 An EGLDisplay supporting EGL_EXT_output_openwf must be associated 50 with an EGLDevice supporting EGL_EXT_device_openwf. 51 52Overview 53 54 Increasingly, EGL and its client APIs are being used in place of 55 "native" rendering APIs to implement the basic graphics 56 functionality of native windowing systems. This creates demand 57 for a method to initialize EGL displays and surfaces directly on 58 top of native GPU or device objects rather than native window 59 system objects. The mechanics of enumerating the underlying 60 native devices and constructing EGL displays and surfaces from 61 them have been solved in various platform and implementation- 62 specific ways. The EGL device family of extensions offers a 63 standardized framework for bootstrapping EGL without the use of 64 any underlying "native" APIs or functionality. 65 66 These extensions define how to map device and output handles between 67 EGL and OpenWF Display. An EGL implementation which provides these 68 extensions must have access to sufficient knowledge of the OpenWF 69 implementation to be able to perform these mappings. No requirements 70 are imposed on how this information is obtained, nor does this 71 support have any implications for how EGL devices and outputs are 72 implemented. An implementation which supports these extensions may 73 support other low level device interfaces, such as DRM/KMS, as well. 74 75New Types 76 77 None 78 79New Procedures and Functions 80 81 None 82 83New Tokens 84 85 Added by EXT_device_openwf: 86 87 Accepted as the <attribute> parameter of eglQueryDeviceAttribEXT 88 89 EGL_OPENWF_DEVICE_ID_EXT 0x3237 90 91 If EGL_EXT_platform_device is present, the following is accepted 92 in the <attrib_list> of eglGetPlatformDisplayEXT(). 93 94 EGL_OPENWF_DEVICE_EXT 0x333D 95 96 Added by EXT_output_openwf: 97 98 Accepted in the <attrib_list> of eglGetOutputLayersEXT and as 99 the <attribute> parameter of eglQueryOutputLayerAttribEXT 100 101 EGL_OPENWF_PIPELINE_ID_EXT 0x3238 102 103 Accepted in the <attrib_list> of eglGetOutputPortsEXT and as 104 the <attribute> parameter of eglQueryOutputPortAttribEXT 105 106 EGL_OPENWF_PORT_ID_EXT 0x3239 107 108New Behavior for EXT_device_openwf 109 110 EGLDeviceEXTs may be mapped to OpenWF Display devices. 111 112 To obtain a WFD_DEVICE_ID for an EGLDeviceEXT, call 113 eglQueryDeviceAtribEXT with <attribute> set to 114 EGL_OPENWF_DEVICE_ID_EXT. 115 116If EGL_EXT_platform_device is present, replace the last sentence of the 117third paragraph in section 3.2 "Initialization" with the following: 118 119 When <platform> is EGL_PLATFORM_DEVICE_EXT, the only valid attribute 120 name is EGL_OPENWF_DEVICE_EXT. If specified, the value must be a 121 WFDDevice created with the device ID returned by querying 122 EGL_OPENWF_DEVICE_ID_EXT from the specified EGLDevice. If the device 123 handle does not refer to the correct OpenWF device the behavior is 124 undefined. Calls to eglGetPlatformDeviceEXT() with the same values 125 for <platform> and <native_display> but distinct EGL_OPENWF_DEVICE_EXT 126 values will return separate EGLDisplays. 127 128 EGL may require the use of the OpenWF device beyond the duration of 129 the call to eglGetPlatformDisplayEXT(). The application must ensure 130 the device handle remains valid for the lifetime of the display 131 returned. If no OpenWF device handle is specified and EGL requires 132 one, it will attempt to create the device itself. Applications 133 should only need to specify an OpenWF device in situations where EGL 134 may fail to create one itself due to an existing instance of the same 135 underlying device in the process. 136 137New Behavior for EXT_output_openwf 138 139 OpenWF pipeline and port IDs may be used to restrict EGL output 140 handle searches and may be queried from EGL output handles. 141 142 Add to Table 3.10.3.1 in EGL_EXT_output_base: 143 144 Attribute Type Access 145 -------------------------- ------- ------ 146 EGL_OPENWF_PIPELINE_ID_EXT integer S|R 147 148 Add to Table 3.10.3.2 in EGL_EXT_output_base: 149 150 Attribute Type Access 151 -------------------------- ------- ------ 152 EGL_OPENWF_PORT_ID_EXT integer S|R 153 154Issues 155 156 1. Although the overview says that we do not impose any 157 restrictions on how the features are implemented, restrictions 158 in the OpenWF specification combined with the chosen interface 159 here do implicitly impose limitations. Specifically, the 160 wfdCreate* functions can only be called once to obtain OpenWF 161 handles. This means that an EGLDevice/Output implementation 162 cannot be layered on top of OpenWF without preventing the 163 application from calling these functions. So we must assume that 164 the implementation instead has some backdoor into OpenWF to 165 obtain the object IDs. Possible resolutions include: 166 a) Keep the access model as is. This assumption is a reasonable 167 one. 168 b) Flip the requirement. The EGL device/output implementation 169 should always create the OpenWF handles itself. We can add 170 queries so that the application can get these handles from 171 EGL. 172 c) Generalize this extension to support both models. The 173 application would have to first query EGL to determine 174 whether or not it owns the handles, and then be prepared to 175 either query them from EGL or create them itself. 176 d) Require the application to provide its OpenWF device handle 177 if it has one. 178 179 RESOLVED: (d), though implementations are free to use (a) when 180 possible. 181 182 2. Should different values of EGL_OPENWF_DEVICE_EXT result in separate 183 EGLDisplays? 184 185 RESOLVED: Yes. Consider an application made up of two independent 186 modules running in two independently scheduled threads. Each 187 module calls eglGetPlatformDisplayEXT(): 188 189 WFDDevice wfdDev = wfdCreateDevice(WFD_DEFAULT_DEVICE_ID, NULL); 190 int attr1[] = { EGL_OPENWF_DEVICE_EXT, wfdDev }; 191 dpy1 = eglGetPlatformDisplayEXT(EGL_PLATFORM_DEVICE_EXT, 192 eglDev, 193 attr1); 194 195 ... 196 197 dpy2 = eglGetPlatformDisplayEXT(EGL_PLATFORM_DEVICE_EXT, 198 eglDev, 199 NULL); 200 201 Presumably, if dpy1 == dpy2, they would both be using the same 202 WFDDevice for output operations internally. That would mean 203 output operations would likely fail if dpy2 happened to be created 204 before dpy1. This would be painful to debug. If dpy2 != dpy1, 205 failure for dpy2 would be consistent and obvious. The application 206 author would be required to work out a scheme to share the WFDDevice 207 between modules before creating EGL displays. 208 209Revision History: 210 211 #5 (January 21st, 2016) James Jones 212 - Add EGL_OPENWF_DEVICE_EXT to resolve issue 1. 213 - Added possible solution (d) to issue 1, and resolve to use it. 214 - Added issue 2. 215 216 #4 (August 22nd, 2014) James Jones 217 - Marked complete. 218 - Listed Daniel as the contact. 219 220 #3 (June 5th, 2014) Daniel Kartch 221 - Assign enumerated values for constants. 222 223 #2 (May 28th, 2014) Daniel Kartch 224 - Simplified description of new behavior based on refinements 225 to EGL_EXT_output_base. 226 227 #1 (January 31st, 2014) Daniel Kartch 228 - Initial draft, representing a signficant reworking of 229 functionality previously proposed in 230 EGL_EXT_native_device_openwf. 231