1Name 2 3 ARM_implicit_external_sync 4 5Name Strings 6 7 EGL_ARM_implicit_external_sync 8 9Contributors 10 11 David Garbett 12 Ray Smith 13 14Contacts 15 16 David Garbett, ARM Ltd. (david 'dot' garbett 'at' arm 'dot' com) 17 18Status 19 20 Draft 21 22Version 23 24 Version 1, September 8, 2014 25 26Number 27 28 EGL Extension #103 29 30Dependencies 31 32 Requires EGL 1.1. 33 34 This extension is written against the wording of the EGL 1.2 Specification. 35 36 EGL_KHR_fence_sync is required. 37 38Overview 39 40 This extension extends the "fence sync objects" defined in 41 EGL_KHR_fence_sync. It allows the condition that triggers the associated 42 fence command in the client API command stream to be explicitly specified on 43 fence object creation. It introduces a new condition that can be used to 44 ensure ordering between operations on buffers that may be accessed 45 externally to the client API, when those operations use an implicit 46 synchronization mechanism. Such a fence object will be signaled when all 47 prior commands affecting such buffers are guaranteed to be executed before 48 such external commands. 49 50 Applications have limited control over when a native buffer is read or 51 written by the GPU when imported as an EGLImageKHR or via 52 eglCreatePixmapSurface, which is controlled by the EGL and client API 53 implementations. While eglWaitClient or a client call such as glFinish 54 could be called, this forces all rendering to complete, which can result in 55 CPU/GPU serialization. Note this isn't an issue for window surfaces, where 56 eglSwapBuffers ensures the rendering occurs in the correct order for the 57 platform. 58 59 Some platforms have an implicit synchronization mechanism associated with 60 native resources, such as buffers. This means that accesses to the buffer 61 have an implicit ordering imposed on them, without involvement from the 62 application. However, this requires that an application that has imported 63 an affected buffer into EGL has a mechanism to flush any drawing operations 64 in flight such that they are waiting on the synchronization mechanism. 65 Otherwise the application cannot guarantee that subsequent operations (such 66 as displaying a rendered buffer) will occur after the commands performed by 67 the client API (such as rendering the buffer). 68 69 The mechanism to wait for the synchronization mechanism should not require 70 the application to wait for all rendering to complete, so that it can 71 continue preparing further commands asynchronously to the queued commands. 72 This extension provides this functionality using the new condition type for 73 fence sync objects, so the application only waits for the external 74 synchronization. 75 76New Types 77 78 None 79 80New Procedures and Functions 81 82 None 83 84New Tokens 85 86 Accepted as a value of the EGL_SYNC_CONDITION_KHR attribute passed in the 87 <attrib_list> list to eglCreateSyncKHR when <type> is EGL_FENCE_SYNC_KHR, 88 and can populate <*value> when eglGetSyncAttribKHR is called with 89 <attribute> set to EGL_SYNC_CONDITION_KHR: 90 91 EGL_SYNC_PRIOR_COMMANDS_IMPLICIT_EXTERNAL_ARM 0x328A 92 93Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) 94 95 Add the following after the fifth paragraph of Section 3.8.1 (Sync Objects), 96 added by KHR_fence_sync: 97 98 "Typically client APIs are considered to execute commands in a linear queue, 99 where a prior command is executed and completes before a later command is 100 started. By default fence sync objects adhere to this model - a fence is 101 signaled once prior commands have completed. However on some platforms a 102 command in a client API may transition through multiple states before it 103 completes, which may impact other components of the system. Therefore the 104 condition that all prior commands must meet before the fence is triggered is 105 configurable." 106 107 Replace the sixth paragraph of Section 3.8.1 (Sync Objects), added by 108 KHR_fence_sync: 109 110 "If, <type> is EGL_SYNC_FENCE_KHR, a fence sync object is created. In this 111 case <attrib_list> can be NULL or empty, or can specify the 112 EGL_SYNC_CONDITION_KHR attribute. Attributes of the fence sync object have 113 the following default values:" 114 115 Replace the eighth paragraph of Section 3.8.1 (Sync Objects), added by 116 KHR_fence_sync: 117 118 "When the condition of the sync object is satisfied by the fence command, 119 the sync is signaled by the associated client API context, causing any 120 eglClientWaitSyncKHR commands (see below) blocking on <sync> to unblock. The 121 condition is specified by the EGL_SYNC_CONDITION_KHR attribute passed to 122 eglCreateSyncKHR. 123 124 If the condition is specified as EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR, the 125 fence sync object is satisfied by completion of the fence command 126 corresponding to the sync object, and all preceding commands in the 127 associated client API context's command stream. The sync object will not be 128 signaled until all effects from these commands on the client API's internal 129 and framebuffer state are fully realized. No other state is affected by 130 execution of the fence command. 131 132 If the condition is specified as 133 EGL_SYNC_PRIOR_COMMANDS_IMPLICIT_EXTERNAL_ARM, the fence sync object is 134 satisfied by the completion of the fence command corresponding to the sync 135 object, and the <submission> of all preceding commands in the associated 136 client API context's command stream. <Submission> defines the point in time 137 when a command has been queued on any implicit synchronization mechanisms 138 present on the platform which apply to any of the resources used by the 139 command. This enforces an ordering, as defined by the synchronization 140 mechanism, between the command and any other operations that also respect 141 the synchronization mechanism(s)." 142 143 Replace the second entry in the list of eglCreateSyncKHR errors in Section 144 3.8.1 (Sync Objects), added by KHR_fence_sync: 145 146 " * If <type> is EGL_SYNC_FENCE_KHR and <attrib_list> contains an attribute 147 other than EGL_SYNC_CONDITION_KHR, EGL_NO_SYNC_KHR is returned and an 148 EGL_BAD_ATTRIBUTE error is generated. 149 * If <type> is EGL_SYNC_FENCE_KHR and the value specified for 150 EGL_SYNC_CONDITION_KHR is not EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR or 151 EGL_SYNC_PRIOR_COMMANDS_SUBMITTED_ARM, EGL_NO_SYNC_KHR is returned and 152 an EGL_BAD_ATTRIBUTE error is generated." 153 154Issues 155 156 1. Could glFlush guarantee commands are submitted, making this extension 157 unnecessary? 158 159 RESOLVED: The Open GL ES 3.1 specification defines glFlush() as causing "all 160 previously issued GL commands to complete in finite time". There is no 161 requirement for the execution of commands to reach any specific point before 162 it returns - a valid implementation of glFlush() could spawn a new thread 163 that sleeps for a minute before submitting the pending commands. While an 164 implementation could decide to ensure all commands are submitted within 165 glFlush(), it could not be assumed to be the case across all 166 implementations. 167 168 In addition, there may be scenarios when submitting commands within 169 glFlush() is harmful. Waiting for command submission may have a performance 170 impact on some implementations that perform processing of commands 171 asynchronously. In addition such a change may restrict what is possible in 172 the future. For example if user events were introduced into OpenGL ES they 173 have the potential of introducing deadlocks if submission in glFlush() is 174 guaranteed. 175 176 2. Should a new entry point be defined that flushes commands synchronously, 177 instead of the new fence type as defined by this extension? 178 179 RESOLVED: While a synchronous "flush and submit" entrypoint would meet the 180 requirements for this extension, there may be a small benefit in enabling 181 the application to continue processing between flushing and waiting for 182 submission. In addition, the semantics of the existing EGL_KHR_fence_sync 183 extension closely match what is required for this extension, so defining 184 the new functionality in terms of fences may enable simpler implementations. 185 186 3. Should OpenGL ES 3 glFenceSync be extended in preference to 187 eglCreateSyncKHR? 188 189 RESOLVED: Some platforms are yet to move to a OpenGL ES 3 implementation, or 190 may be unwilling to expose OpenGL ES 3 entrypoints to applications. As 191 EGL_KHR_fence_sync is older than OpenGL ES 3, and is comparatively a small 192 change, it has a better chance of adoption in a platform. 193 194 In addition this extension is based on the idea that there are 195 platform-specific ways to interact with the client API command stream. As 196 this is platform-specific, and does not fit with the existing model 197 typically used by client APIs (such as Open GL ES) it is better placed in 198 EGL. 199 200 Finally extending EGL has the advantage that the extension applies to all 201 client APIs. 202 203 4. Should a new <type> parameter be defined, instead of extending the 204 EGL_FENCE_SYNC_KHR fence sync objects defined by EGL_KHR_fence_sync? 205 206 RESOLVED: Whether the new functionality is defined as an extension to the 207 existing fence sync objects, or whether they are defined as a new type of 208 sync object, we must acknowledge that the model of a client API processing 209 commands serially (with prior commands completing before later commands are 210 executed) is too simplistic for some platforms. 211 212 Extending the existing fence sync objects allows us to use the existing 213 concept of conditions that trigger the fences. It also allows the maximum 214 amount of reuse of existing functionality, potentially simplifying the 215 implementation and the use of the extension by applications. 216 217Revision History 218#1 (David Garbett, September 8, 2014) 219 - Initial draft. 220