blob: 2fb4d3b070bb8a181f47cdb9666f5b1daeaef27e [file] [log] [blame]
Name Strings
Daniel Kartch
James Jones
Christopher James Halse Rogers
Daniel Kartch, NVIDIA (dkartch 'at'
Version 5 - January 21, 2016
EGL Extension #80
Extension Type
EGL device extension for EGL_EXT_device_openwf
EGL display extension for EGL_EXT_output_openwf
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.
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
New Procedures and Functions
New Tokens
Added by EXT_device_openwf:
Accepted as the <attribute> parameter of eglQueryDeviceAttribEXT
If EGL_EXT_platform_device is present, the following is accepted
in the <attrib_list> of eglGetPlatformDisplayEXT().
Added by EXT_output_openwf:
Accepted in the <attrib_list> of eglGetOutputLayersEXT and as
the <attribute> parameter of eglQueryOutputLayerAttribEXT
Accepted in the <attrib_list> of eglGetOutputPortsEXT and as
the <attribute> parameter of eglQueryOutputPortAttribEXT
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
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 in EGL_EXT_output_base:
Attribute Type Access
-------------------------- ------- ------
Add to Table in EGL_EXT_output_base:
Attribute Type Access
-------------------------- ------- ------
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
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
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
2. Should different values of EGL_OPENWF_DEVICE_EXT result in separate
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,
dpy2 = eglGetPlatformDisplayEXT(EGL_PLATFORM_DEVICE_EXT,
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