diff options
Diffstat (limited to 'glew/auto/EGL-Registry/extensions/KHR/EGL_KHR_cl_event.txt')
| -rw-r--r-- | glew/auto/EGL-Registry/extensions/KHR/EGL_KHR_cl_event.txt | 278 |
1 files changed, 278 insertions, 0 deletions
diff --git a/glew/auto/EGL-Registry/extensions/KHR/EGL_KHR_cl_event.txt b/glew/auto/EGL-Registry/extensions/KHR/EGL_KHR_cl_event.txt new file mode 100644 index 0000000..92f4a73 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/KHR/EGL_KHR_cl_event.txt @@ -0,0 +1,278 @@ +Name + + KHR_cl_event + +Name Strings + + EGL_KHR_cl_event + +Contributors + + Jon Leech, Khronos + Alon Or-bach, Samsung Electronics + +Contact + + Jon Leech (jon 'at' alumni.caltech.edu) + +IP Status + + No known claims. + +Notice + + Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at + http://www.khronos.org/registry/speccopyright.html + +Status + + This extension is obsolete and has been replaced by EGL_KHR_cl_event2. + Khronos recommends implementers who support this extension also + implement cl_event2, and begin transitioning developers to using that + extension. See issue 17 for the reason. + + Complete. Approved by the EGL Working Group on 2013/05/15. + Approved by the Khronos Board of Promoters on 2013/07/19. + +Version + + Version 10, December 4, 2013 + +Number + + EGL Extension #60 + +Dependencies + + EGL 1.4 and the EGL_KHR_fence_sync extension are required. + + This extension is written against the language added to EGL 1.2 by + the EGL_KHR_fence_sync extension. + + An OpenCL implementation supporting sharing OpenCL event objects + with EGL is required. + +Overview + + This extension allows creating an EGL fence sync object linked to an + OpenCL event object, potentially improving efficiency of sharing + images between the two APIs. The companion cl_khr_egl_event + extension provides the complementary functionality of creating an + OpenCL event object from an EGL fence sync object. + +New Types + + None. However, event handles of type cl_event, defined in the OpenCL + header files, may be included in the attribute list passed to + eglCreateSyncKHR. + +New Procedures and Functions + + None + +New Tokens + + Accepted as attribute names in the <attrib_list> argument + of eglCreateSyncKHR: + + EGL_CL_EVENT_HANDLE_KHR 0x309C + + Returned in <values> for eglGetSyncAttribKHR <attribute> + EGL_SYNC_TYPE_KHR: + + EGL_SYNC_CL_EVENT_KHR 0x30FE + + Returned in <values> for eglGetSyncAttribKHR <attribute> + EGL_SYNC_CONDITION_KHR: + + EGL_SYNC_CL_EVENT_COMPLETE_KHR 0x30FF + +Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) + + Add following the description of fence sync objects in section 3.8.1 + (e.g. following the paragraph beginning "<Fence sync objects> are + created..." + + "A <CL event sync object> reflects the status of a corresponding + OpenCL event object to which the sync object is linked. This + provides another method of coordinating sharing of images between + EGL and OpenCL (see Chapter 9 of the OpenCL 1.0 Specification and + the cl_khr_egl_sharing extension). Waiting on such a sync object is + equivalent to waiting for completion of the linked CL event object." + + Add following the description of fence sync objects (prior to the + "Errors" section for eglCreateSyncKHR): + + "If <type> is EGL_SYNC_CL_EVENT_KHR, a CL event sync object is + created. In this case <attrib_list> must contain the attribute + EGL_CL_EVENT_HANDLE_KHR, set to a valid OpenCL event. Note that + EGL_CL_EVENT_HANDLE_KHR is not a queriable property of a sync + object. Attributes of the CL event sync objects are set as follows: + + Attribute Name Initial Attribute Value(s) + ------------- -------------------------- + EGL_SYNC_TYPE_KHR EGL_SYNC_CL_EVENT_KHR + EGL_SYNC_STATUS_KHR Depends on status of <event> + EGL_SYNC_CONDITION_KHR EGL_SYNC_CL_EVENT_COMPLETE_KHR + + The status of such a sync object depends on <event>. When the status + of <event> is CL_QUEUED, CL_SUBMITTED, or CL_RUNNING, the status of + the linked sync object will be EGL_UNSIGNALED_KHR. When the status + of <event> changes to CL_COMPLETE, the status of the linked sync + object will become EGL_SIGNALED_KHR. + + Creating a linked sync object places a reference on the linked + OpenCL event object. When the sync object is deleted, the reference + will be removed from the event object. + + However, implementations are not required to validate the OpenCL + event, and passing an invalid event handle in <attrib_list> may + result in undefined behavior up to and including program + termination." + + Add to the "Errors" section for eglCreateSyncKHR: + + "* If <type> is EGL_SYNC_CL_EVENT_KHR then + + ** If EGL_CL_EVENT_HANDLE_KHR is not specified in <attrib_list> + or is not a valid OpenCL event handle returned by a call to + clEnqueueReleaseGLObjects or clEnqueueReleaseEGLObjects, then + EGL_NO_SYNC_KHR is returned and an EGL_BAD_ATTRIBUTE error is + generated. + + Replace the EGL_SYNC_CONDITION_KHR row of table 3.cc with: + + "Attribute Description Supported Sync Objects + ----------------- ----------------------- ---------------------- + EGL_SYNC_CONDITION_KHR Signaling condition EGL_SYNC_FENCE_KHR or + EGL_SYNC_CL_EVENT_KHR + + Table 3.cc Attributes Accepted by eglGetSyncAttribKHR Command" + + + Replace the second paragraph describing eglDestroySync with: + + "If any eglClientWaitSyncKHR commands are blocking on <sync> when + eglDestroySyncKHR is called, <sync> is flagged for deletion and will + be deleted when the associated fence command or CL event object has + completed, and <sync> is no longer blocking any eglClientWaitSyncKHR + command. Otherwise, the sync object is destroyed immediately." + +Sample Code + + None + +Conformance Tests + + None yet + +Issues + + 1) Does this extension need to introduce eglWaitSync + functionality? + + RESOLVED: The EGL_KHR_wait_sync extension introduces this, to allow + server-side synchronization, without blocking the client from issuing + commands. Whilst this is not a required dependency, GPU-to-GPU + synchronization is the most likely use of this extension. + + 2) What should the command to create a sync object linked to an + OpenCL event look like? + + RESOLVED: We reuse the general attribute list mechanism rather than + having a constructor specific to CL events. This was intended in the + sync object design from the start. + + 3) How will the OpenCL header dependencies interact with + specifying the API for this extension? + + DISCUSSION: To use this extension, OpenCL event handles of type cl_event + are specified in the attribute lists passed to eglCreateSyncKHR. Because + no formal parameters are of type cl_event, the EGL headers do not need + to define this type. Applications must #include the appropriate OpenCL + header files as well as <EGL/eglext.h> when using this extension. + + This issue resolution is consistent with the equivalent issue for + GL_ARB_cl_event. + + 4) Should all possible statuses of the CL event be reflected through to the + state of the sync object? + + DISCUSSION: CL event objects have four execution statuses: + CL_QUEUED, CL_SUBMITTED, CL_RUNNING, and CL_COMPLETE. GL sync + objects have only two statuses: UNSIGNALED and SIGNALED. The + cl_khr_gl_event extension maps UNSIGNALED into CL_SUBMITTED, and + SIGNALED into CL_COMPLETE. + + RESOLVED: Invert the cl_khr_egl_event mapping. CL_QUEUED, + CL_SUBMITTED, and CL_RUNNING all map into UNSIGNALED. + CL_COMPLETE maps into SIGNALED. + + This issue resolution is consistent with the equivalent issue for + GL_ARB_cl_event. + + 5) Are there any restrictions on the use of a sync object linked to a CL + event object? + + RESOLVED: No restrictions. + + 6) How are sync object lifetimes defined? + + RESOLVED: A sync object linked to a CL event object places a single + reference on the event. Deleting the sync object removes that reference. + + eglDestroySync has a dependency on the completion of the linked event + object, and will not delete the sync objectwhile the event object has not + yet completed. This is equivalent to behavior of deleting a fence sync + object, where deletion of the object will be deferred until the underlying + fence command has completed. + + This issue resolution is consistent with the equivalent issue for + GL_ARB_cl_event. + + 7) Should all OpenCL events be supported? + + RESOLVED: No. Only events returned by clEnqueueReleaseGLObjects, or + clEnqueueReleaseEGLObjects since those are the only known use cases for + this extension. + + 8) Why has this extension been obsoleted and replaced by + EGL_KHR_cl_event2? + + RESOLVED: Starting with the December 4, 2013 release of EGL 1.4, EGLint + is defined to be the same size as the native platform "int" type. Handle + and pointer attribute values *cannot* be represented in attribute lists + on platforms where sizeof(handle/pointer) > sizeof(int). Existing + extensions which assume this functionality are being replaced with new + extensions specifying new entry points to work around this issue. See + the latest EGL 1.4 Specification for more details. + +Revision History + + Version 10, 2013/12/04 (Jon Leech) - add issue 8 explaining that OpenCL + event handles cannot be safely passed in attribute lists on 64-bit + platforms, and suggest using EGL_KHR_cl_event2 instead. + + Version 9, 2013/08/12 (Jon Leech) - remove unused cl_event type from the + extension and from <EGL/eglext.h> (Bug 10661). + + Version 8, 2013/07/19 (Jon Leech) - assign extension number and + missing enum value, and clean up a few typos for publication. + + Version 7, 2013/07/08 (Jon Leech) - assign enums (Bug 10490). + + Version 6, 2013/06/11 (Alon Or-bach) - typo correction + + Version 5, 2013/05/30 (Alon Or-bach) - wording cleanup + + Version 4, 2013/05/15 (Alon Or-bach) - updated issue resolutions as agreed, + consistent with GL_ARB_cl_event, including using typedef for cl_event + + Version 3, 2013/04/25 (Alon Or-bach) - remove use of CL context, + accept events from clEnqueueAcquireEGLObjects and minor cleanup + + Version 2, 2012/06/26 (Jon Leech) - update link to complementary CL + extension. + + Version 1, 2010/05/18 (Jon Leech) - initial version based on + equivalent GL_ARB_cl_event extension. |