diff options
Diffstat (limited to 'glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_implicit_external_sync.txt')
| -rw-r--r-- | glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_implicit_external_sync.txt | 219 |
1 files changed, 219 insertions, 0 deletions
diff --git a/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_implicit_external_sync.txt b/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_implicit_external_sync.txt new file mode 100644 index 0000000..bce6a74 --- /dev/null +++ b/glew/auto/EGL-Registry/extensions/ARM/EGL_ARM_implicit_external_sync.txt @@ -0,0 +1,219 @@ +Name + + ARM_implicit_external_sync + +Name Strings + + EGL_ARM_implicit_external_sync + +Contributors + + David Garbett + Ray Smith + +Contacts + + David Garbett, ARM Ltd. (david 'dot' garbett 'at' arm 'dot' com) + +Status + + Draft + +Version + + Version 1, September 8, 2014 + +Number + + EGL Extension #103 + +Dependencies + + Requires EGL 1.1. + + This extension is written against the wording of the EGL 1.2 Specification. + + EGL_KHR_fence_sync is required. + +Overview + + This extension extends the "fence sync objects" defined in + EGL_KHR_fence_sync. It allows the condition that triggers the associated + fence command in the client API command stream to be explicitly specified on + fence object creation. It introduces a new condition that can be used to + ensure ordering between operations on buffers that may be accessed + externally to the client API, when those operations use an implicit + synchronization mechanism. Such a fence object will be signaled when all + prior commands affecting such buffers are guaranteed to be executed before + such external commands. + + Applications have limited control over when a native buffer is read or + written by the GPU when imported as an EGLImageKHR or via + eglCreatePixmapSurface, which is controlled by the EGL and client API + implementations. While eglWaitClient or a client call such as glFinish + could be called, this forces all rendering to complete, which can result in + CPU/GPU serialization. Note this isn't an issue for window surfaces, where + eglSwapBuffers ensures the rendering occurs in the correct order for the + platform. + + Some platforms have an implicit synchronization mechanism associated with + native resources, such as buffers. This means that accesses to the buffer + have an implicit ordering imposed on them, without involvement from the + application. However, this requires that an application that has imported + an affected buffer into EGL has a mechanism to flush any drawing operations + in flight such that they are waiting on the synchronization mechanism. + Otherwise the application cannot guarantee that subsequent operations (such + as displaying a rendered buffer) will occur after the commands performed by + the client API (such as rendering the buffer). + + The mechanism to wait for the synchronization mechanism should not require + the application to wait for all rendering to complete, so that it can + continue preparing further commands asynchronously to the queued commands. + This extension provides this functionality using the new condition type for + fence sync objects, so the application only waits for the external + synchronization. + +New Types + + None + +New Procedures and Functions + + None + +New Tokens + + Accepted as a value of the EGL_SYNC_CONDITION_KHR attribute passed in the + <attrib_list> list to eglCreateSyncKHR when <type> is EGL_FENCE_SYNC_KHR, + and can populate <*value> when eglGetSyncAttribKHR is called with + <attribute> set to EGL_SYNC_CONDITION_KHR: + + EGL_SYNC_PRIOR_COMMANDS_IMPLICIT_EXTERNAL_ARM 0x328A + +Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) + + Add the following after the fifth paragraph of Section 3.8.1 (Sync Objects), + added by KHR_fence_sync: + + "Typically client APIs are considered to execute commands in a linear queue, + where a prior command is executed and completes before a later command is + started. By default fence sync objects adhere to this model - a fence is + signaled once prior commands have completed. However on some platforms a + command in a client API may transition through multiple states before it + completes, which may impact other components of the system. Therefore the + condition that all prior commands must meet before the fence is triggered is + configurable." + + Replace the sixth paragraph of Section 3.8.1 (Sync Objects), added by + KHR_fence_sync: + + "If, <type> is EGL_SYNC_FENCE_KHR, a fence sync object is created. In this + case <attrib_list> can be NULL or empty, or can specify the + EGL_SYNC_CONDITION_KHR attribute. Attributes of the fence sync object have + the following default values:" + + Replace the eighth paragraph of Section 3.8.1 (Sync Objects), added by + KHR_fence_sync: + + "When the condition of the sync object is satisfied by the fence command, + the sync is signaled by the associated client API context, causing any + eglClientWaitSyncKHR commands (see below) blocking on <sync> to unblock. The + condition is specified by the EGL_SYNC_CONDITION_KHR attribute passed to + eglCreateSyncKHR. + + If the condition is specified as EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR, the + fence sync object is satisfied by completion of the fence command + corresponding to the sync object, and all preceding commands in the + associated client API context's command stream. The sync object will not be + signaled until all effects from these commands on the client API's internal + and framebuffer state are fully realized. No other state is affected by + execution of the fence command. + + If the condition is specified as + EGL_SYNC_PRIOR_COMMANDS_IMPLICIT_EXTERNAL_ARM, the fence sync object is + satisfied by the completion of the fence command corresponding to the sync + object, and the <submission> of all preceding commands in the associated + client API context's command stream. <Submission> defines the point in time + when a command has been queued on any implicit synchronization mechanisms + present on the platform which apply to any of the resources used by the + command. This enforces an ordering, as defined by the synchronization + mechanism, between the command and any other operations that also respect + the synchronization mechanism(s)." + + Replace the second entry in the list of eglCreateSyncKHR errors in Section + 3.8.1 (Sync Objects), added by KHR_fence_sync: + + " * If <type> is EGL_SYNC_FENCE_KHR and <attrib_list> contains an attribute + other than EGL_SYNC_CONDITION_KHR, EGL_NO_SYNC_KHR is returned and an + EGL_BAD_ATTRIBUTE error is generated. + * If <type> is EGL_SYNC_FENCE_KHR and the value specified for + EGL_SYNC_CONDITION_KHR is not EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR or + EGL_SYNC_PRIOR_COMMANDS_SUBMITTED_ARM, EGL_NO_SYNC_KHR is returned and + an EGL_BAD_ATTRIBUTE error is generated." + +Issues + + 1. Could glFlush guarantee commands are submitted, making this extension + unnecessary? + + RESOLVED: The Open GL ES 3.1 specification defines glFlush() as causing "all + previously issued GL commands to complete in finite time". There is no + requirement for the execution of commands to reach any specific point before + it returns - a valid implementation of glFlush() could spawn a new thread + that sleeps for a minute before submitting the pending commands. While an + implementation could decide to ensure all commands are submitted within + glFlush(), it could not be assumed to be the case across all + implementations. + + In addition, there may be scenarios when submitting commands within + glFlush() is harmful. Waiting for command submission may have a performance + impact on some implementations that perform processing of commands + asynchronously. In addition such a change may restrict what is possible in + the future. For example if user events were introduced into OpenGL ES they + have the potential of introducing deadlocks if submission in glFlush() is + guaranteed. + + 2. Should a new entry point be defined that flushes commands synchronously, + instead of the new fence type as defined by this extension? + + RESOLVED: While a synchronous "flush and submit" entrypoint would meet the + requirements for this extension, there may be a small benefit in enabling + the application to continue processing between flushing and waiting for + submission. In addition, the semantics of the existing EGL_KHR_fence_sync + extension closely match what is required for this extension, so defining + the new functionality in terms of fences may enable simpler implementations. + + 3. Should OpenGL ES 3 glFenceSync be extended in preference to + eglCreateSyncKHR? + + RESOLVED: Some platforms are yet to move to a OpenGL ES 3 implementation, or + may be unwilling to expose OpenGL ES 3 entrypoints to applications. As + EGL_KHR_fence_sync is older than OpenGL ES 3, and is comparatively a small + change, it has a better chance of adoption in a platform. + + In addition this extension is based on the idea that there are + platform-specific ways to interact with the client API command stream. As + this is platform-specific, and does not fit with the existing model + typically used by client APIs (such as Open GL ES) it is better placed in + EGL. + + Finally extending EGL has the advantage that the extension applies to all + client APIs. + + 4. Should a new <type> parameter be defined, instead of extending the + EGL_FENCE_SYNC_KHR fence sync objects defined by EGL_KHR_fence_sync? + + RESOLVED: Whether the new functionality is defined as an extension to the + existing fence sync objects, or whether they are defined as a new type of + sync object, we must acknowledge that the model of a client API processing + commands serially (with prior commands completing before later commands are + executed) is too simplistic for some platforms. + + Extending the existing fence sync objects allows us to use the existing + concept of conditions that trigger the fences. It also allows the maximum + amount of reuse of existing functionality, potentially simplifying the + implementation and the use of the extension by applications. + +Revision History +#1 (David Garbett, September 8, 2014) + - Initial draft. |