Lines Matching refs:sync
48 The original EGLSync extensions separated sync objects into two
49 types: fence sync objects signaled by one time events in an
50 API command pipeline; and reusable sync objects signaled by commands
52 reusability of the event triggering a sync object with the EGLSync
55 Although the event associated with a fence sync object will only
62 This extension allows all sync objects to be reusable. When a sync
65 trigger them. For fence sync objects, this means generating a new
66 fence in the current API. For OpenCL event sync objects, this means
68 sync objects to be created in the signaled state with no associated
85 EGLSync sync,
95 operations within a thread, <sync objects> are provided to enable
102 to wait for a sync object to become signaled, or a sync object�s
105 Depending on the type of a sync object, its status may be changed
107 unsignaling the sync. All sync objects are reusable. Once they enter
113 sync object. All sync objects include attributes for their type and
115 different types of sync objects. If a sync object is created in the
120 <Fence sync objects> have an associated fence command in a client
121 API. A new fence command is generated whenever the sync object
124 sync object. Fence sync objects may not be explicitly signaled.
125 Fence sync objects may be used to wait for partial completion of a
129 An <OpenCL event sync object> reflects the status of a corresponding
130 OpenCL event object to which the sync object is linked. This
133 the cl_khr_egl_image extension). Waiting on such a sync object is
142 creates a sync object of the specified <type> associated with the
145 attributes of the sync object, terminated by an attribute entry
149 The EGL_SYNC_STATUS attribute is defined for all sync types, but may
150 only be specified explicitly at creation time for some types of sync
152 indicated below for the sync type.
160 allowed for the type of sync object being created, an
162 If <type> is not a supported type of sync object, an
175 with a sync object cannot be changed. When the <condition> of a sync
176 object in the unsignaled state is satisfied, the sync is signaled,
178 blocking on the sync to unblock.
180 Once signaled, a sync object may be reused for a new synchronization
183 EGLBoolean eglUnsignalSyncEXT(EGLDisplay dpy, EGLSync sync,
186 can be used to change the <sync> associated with display <dpy> from
188 be used to provide or replace attributes specific to the sync type
189 as discussed below. The sync object's type and condition may not be
195 effect on <sync>.
198 If <sync> is not a valid sync object associated with <dpy>, an
201 type of <sync>, an EGL_BAD_ATTRIBUTE error is generated.
202 If <sync> is already in the unsignaled state, an EGL_BAD_ACCESS
204 If <sync>'s type is EGL_SYNC_FENCE and any of the following are
213 If <sync>'s type is EGL_SYNC_CL_EVENT and EGL_CL_EVENT_HANDLE
219 If type is EGL_SYNC_FENCE, a fence sync object is created. The
222 attributes may be specified for a fence sync object, either with
224 fence sync object are set as shown in table 3.7.
226 When a fence sync object is created in the unsignaled state, or
230 associated with the sync object.
232 The only condition supported for fence sync objects is
234 of the fence command corresponding to the sync object, and all
236 stream. The sync object will not be signaled until all effects from
241 Generation of fence commands for fence sync objects requires support
254 If type is EGL_SYNC_CL_EVENT, an OpenCL event sync object is
256 specified during creation of this type of sync object. If no
258 sync object will be created in the signaled state. Otherwise its
263 To use an OpenCL event sync object, the EGL_SYNC_CL_EVENT attribute
270 a queriable property of a sync object. Queriable attributes of the
271 OpenCL event sync object are set as shown in table 3.8.
273 The status of such a sync object depends on <event>. When the status
275 the linked sync object will be EGL_UNSIGNALED. When the status of
276 <event> changes to CL_COMPLETE, the status of the linked sync object
279 The only condition supported for OpenCL event sync objects is
281 the OpenCL event associated with the sync object changes to
284 Associating an OpenCL event handle with a sync object places a
285 reference on the linked OpenCL object. When the sync object is
289 If EGL_KHR_reusable_sync is present, then for sync objects of type
294 If EGL_ANDROID_native_fence_sync is present, then for native fence sync
304 native fence sync object with an FD of EGL_NO_NATIVE_FENCE_FD_ANDROID,
308 If EGL_NV_cuda_event is present, then for CUDA event sync objects, the
311 the EGL sync object becomes unsignaled, and subsequent modification of
312 the CUDA object with cudaEventRecord has no effect on the sync object
313 until it is signaled. Subsequently restoring the sync object to
318 1. Should a new attribute be required to specify a sync object as
322 indicate reusability of all sync objects. This will not create
323 any incompatibilities with existing applications that use sync
329 RESOLVED: No. Some types of sync objects require attributes
331 for the sync object to be reused. Therefore a new function which
338 RESOLVED: No. While all sync objects will support unsignaling,
339 the reusable sync object is the only known one that supports
347 sync object), should the EGL_SYNC_STATUS default to EGL_SIGNALED
351 is based on the sync type. For fence syncs, either value is
369 time to be determined by the sync type and other attributes.
372 clarify allowed initial states for the sync status and fix the