| Name |
| |
| EXT_device_openwf |
| EXT_output_openwf |
| |
| Name Strings |
| |
| EGL_EXT_device_openwf |
| EGL_EXT_output_openwf |
| |
| Contributors |
| |
| Daniel Kartch |
| James Jones |
| Christopher James Halse Rogers |
| |
| Contacts |
| |
| Daniel Kartch, NVIDIA (dkartch 'at' nvidia.com) |
| |
| Status |
| |
| Complete |
| |
| Version |
| |
| Version 5 - January 21, 2016 |
| |
| Number |
| |
| EGL Extension #80 |
| |
| Extension Type |
| |
| EGL device extension for EGL_EXT_device_openwf |
| |
| EGL display extension for EGL_EXT_output_openwf |
| |
| Dependencies |
| |
| EGL_EXT_device_openwf requires EGL_EXT_device_base. |
| |
| EGL_EXT_output_openwf requires EGL_EXT_output_base. |
| |
| Both require OpenWF Display |
| |
| EGL_EXT_device_openwf interacts with EGL_EXT_platform_device |
| |
| An EGLDisplay supporting EGL_EXT_output_openwf must be associated |
| with an EGLDevice supporting EGL_EXT_device_openwf. |
| |
| 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. |
| |
| These extensions define how to map device and output handles between |
| EGL and OpenWF Display. An EGL implementation which provides these |
| extensions must have access to sufficient knowledge of the OpenWF |
| implementation to be able to perform these mappings. No requirements |
| are imposed on how this information is obtained, nor does this |
| support have any implications for how EGL devices and outputs are |
| implemented. An implementation which supports these extensions may |
| support other low level device interfaces, such as DRM/KMS, as well. |
| |
| New Types |
| |
| None |
| |
| New Procedures and Functions |
| |
| None |
| |
| New Tokens |
| |
| Added by EXT_device_openwf: |
| |
| Accepted as the <attribute> parameter of eglQueryDeviceAttribEXT |
| |
| EGL_OPENWF_DEVICE_ID_EXT 0x3237 |
| |
| If EGL_EXT_platform_device is present, the following is accepted |
| in the <attrib_list> of eglGetPlatformDisplayEXT(). |
| |
| EGL_OPENWF_DEVICE_EXT 0x333D |
| |
| Added by EXT_output_openwf: |
| |
| Accepted in the <attrib_list> of eglGetOutputLayersEXT and as |
| the <attribute> parameter of eglQueryOutputLayerAttribEXT |
| |
| EGL_OPENWF_PIPELINE_ID_EXT 0x3238 |
| |
| Accepted in the <attrib_list> of eglGetOutputPortsEXT and as |
| the <attribute> parameter of eglQueryOutputPortAttribEXT |
| |
| EGL_OPENWF_PORT_ID_EXT 0x3239 |
| |
| New Behavior for EXT_device_openwf |
| |
| EGLDeviceEXTs may be mapped to OpenWF Display devices. |
| |
| To obtain a WFD_DEVICE_ID for an EGLDeviceEXT, call |
| eglQueryDeviceAtribEXT with <attribute> set to |
| EGL_OPENWF_DEVICE_ID_EXT. |
| |
| If EGL_EXT_platform_device is present, replace the last sentence of the |
| third paragraph in section 3.2 "Initialization" with the following: |
| |
| When <platform> is EGL_PLATFORM_DEVICE_EXT, the only valid attribute |
| name is EGL_OPENWF_DEVICE_EXT. If specified, the value must be a |
| WFDDevice created with the device ID returned by querying |
| EGL_OPENWF_DEVICE_ID_EXT from the specified EGLDevice. If the device |
| handle does not refer to the correct OpenWF device the behavior is |
| undefined. Calls to eglGetPlatformDeviceEXT() with the same values |
| for <platform> and <native_display> but distinct EGL_OPENWF_DEVICE_EXT |
| values will return separate EGLDisplays. |
| |
| EGL may require the use of the OpenWF device beyond the duration of |
| the call to eglGetPlatformDisplayEXT(). The application must ensure |
| the device handle remains valid for the lifetime of the display |
| returned. If no OpenWF device handle is specified and EGL requires |
| one, it will attempt to create the device itself. Applications |
| should only need to specify an OpenWF device in situations where EGL |
| may fail to create one itself due to an existing instance of the same |
| underlying device in the process. |
| |
| New Behavior for EXT_output_openwf |
| |
| OpenWF pipeline and port IDs may be used to restrict EGL output |
| handle searches and may be queried from EGL output handles. |
| |
| Add to Table 3.10.3.1 in EGL_EXT_output_base: |
| |
| Attribute Type Access |
| -------------------------- ------- ------ |
| EGL_OPENWF_PIPELINE_ID_EXT integer S|R |
| |
| Add to Table 3.10.3.2 in EGL_EXT_output_base: |
| |
| Attribute Type Access |
| -------------------------- ------- ------ |
| EGL_OPENWF_PORT_ID_EXT integer S|R |
| |
| Issues |
| |
| 1. Although the overview says that we do not impose any |
| restrictions on how the features are implemented, restrictions |
| in the OpenWF specification combined with the chosen interface |
| here do implicitly impose limitations. Specifically, the |
| wfdCreate* functions can only be called once to obtain OpenWF |
| handles. This means that an EGLDevice/Output implementation |
| cannot be layered on top of OpenWF without preventing the |
| application from calling these functions. So we must assume that |
| the implementation instead has some backdoor into OpenWF to |
| obtain the object IDs. Possible resolutions include: |
| a) Keep the access model as is. This assumption is a reasonable |
| one. |
| b) Flip the requirement. The EGL device/output implementation |
| should always create the OpenWF handles itself. We can add |
| queries so that the application can get these handles from |
| EGL. |
| c) Generalize this extension to support both models. The |
| application would have to first query EGL to determine |
| whether or not it owns the handles, and then be prepared to |
| either query them from EGL or create them itself. |
| d) Require the application to provide its OpenWF device handle |
| if it has one. |
| |
| RESOLVED: (d), though implementations are free to use (a) when |
| possible. |
| |
| 2. Should different values of EGL_OPENWF_DEVICE_EXT result in separate |
| EGLDisplays? |
| |
| RESOLVED: Yes. Consider an application made up of two independent |
| modules running in two independently scheduled threads. Each |
| module calls eglGetPlatformDisplayEXT(): |
| |
| WFDDevice wfdDev = wfdCreateDevice(WFD_DEFAULT_DEVICE_ID, NULL); |
| int attr1[] = { EGL_OPENWF_DEVICE_EXT, wfdDev }; |
| dpy1 = eglGetPlatformDisplayEXT(EGL_PLATFORM_DEVICE_EXT, |
| eglDev, |
| attr1); |
| |
| ... |
| |
| dpy2 = eglGetPlatformDisplayEXT(EGL_PLATFORM_DEVICE_EXT, |
| eglDev, |
| NULL); |
| |
| Presumably, if dpy1 == dpy2, they would both be using the same |
| WFDDevice for output operations internally. That would mean |
| output operations would likely fail if dpy2 happened to be created |
| before dpy1. This would be painful to debug. If dpy2 != dpy1, |
| failure for dpy2 would be consistent and obvious. The application |
| author would be required to work out a scheme to share the WFDDevice |
| between modules before creating EGL displays. |
| |
| Revision History: |
| |
| #5 (January 21st, 2016) James Jones |
| - Add EGL_OPENWF_DEVICE_EXT to resolve issue 1. |
| - Added possible solution (d) to issue 1, and resolve to use it. |
| - Added issue 2. |
| |
| #4 (August 22nd, 2014) James Jones |
| - Marked complete. |
| - Listed Daniel as the contact. |
| |
| #3 (June 5th, 2014) Daniel Kartch |
| - Assign enumerated values for constants. |
| |
| #2 (May 28th, 2014) Daniel Kartch |
| - Simplified description of new behavior based on refinements |
| to EGL_EXT_output_base. |
| |
| #1 (January 31st, 2014) Daniel Kartch |
| - Initial draft, representing a signficant reworking of |
| functionality previously proposed in |
| EGL_EXT_native_device_openwf. |
