Lines Matching refs:sync
67 This extension introduces the concept of "sync objects". Sync
70 type of sync object, the "fence sync object", is supported in this
73 Fence sync objects have corresponding fences, which are inserted
74 into the OpenGL command stream at the time the sync object is
75 created. A sync object can be queried for a given condition. The
76 only condition supported for fence sync objects is completion of the
100 sync FenceSync(enum condition,bitfield flags)
101 boolean IsSync(sync sync)
102 void DeleteSync(sync sync)
104 enum ClientWaitSync(sync sync,bitfield flags,uint64 timeout)
105 void WaitSync(sync sync,bitfield flags,uint64 timeout)
108 void GetSynciv(sync sync,enum pname,sizei bufSize,sizei *length,
162 sync <ptrbits> Sync object handle (see section 5.2)
168 describing sync objects and fence operation. Renumber existing
182 <signaled> and <unsignaled>. Events are associated with a sync
183 object. When an sync object is created, its status is set to
184 unsignaled. When the associated event occurs, the sync object is
185 signaled (its status is set to signaled). Once a sync object has
186 been created, the GL may be asked to wait for a sync object to
189 Initially, only one specific type of sync object is defined: the
190 fence sync object, whose associated event is triggered by a fence
191 command placed in the GL command stream. Fence sync objects are used
197 sync FenceSync(enum condition,bitfield flags)
199 creates a new fence sync object, inserts a fence command in the GL
200 command stream and associates it with that sync object, and returns
201 a non-zero name corresponding to the sync object.
203 When the specified <condition> of the sync object is satisfied by
204 the fence command, the sync object is signaled by the GL, causing
206 <sync> to <unblock>. No other state is affected by FenceSync or by
211 sync object and all preceding commands in the same command stream.
212 The sync object will not be signaled until all effects from these
215 state of the corresponding sync object has been changed, but
216 commands waiting on that sync object may not be unblocked until
221 of fence sync object capabilities.]
223 Each sync object contains a number of <properties> which determine
226 The initial property values for a sync object created by FenceSync
237 sync object created with FenceSync().
239 Properties of a sync object may be queried with GetSynciv (see
243 If FenceSync fails to create a sync object, zero will be returned
248 A sync object can be deleted by passing its name to the command
250 void DeleteSync(sync sync)
252 If the fence command corresponding to the specified sync object has
254 on <sync>, the object is deleted immediately. Otherwise, <sync> is
258 from DeleteSync the <sync> name is invalid and can no longer be used
259 to refer to the sync object.
261 DeleteSync will silently ignore a <sync> value of zero. An
262 INVALID_VALUE error is generated if <sync> is neither zero nor the
263 name of a sync object.
271 enum ClientWaitSync(sync sync,bitfield flags,uint64 timeout)
273 causes the GL to block, and will not return until the sync object
274 <sync> is signaled, or until the specified <timeout> period expires.
280 If <sync> is signaled at the time ClientWaitSync is called
281 then ClientWaitSync returns immediately. If <sync> is unsignaled at
283 will wait up to <timeout> nanoseconds for <sync> to become signaled.
288 ALREADY_SIGNALED indicates that <sync> was signaled at the time
290 if <sync> was signaled, even if the value of <timeout> is zero. A
292 period expired before <sync> was signaled. A return value of
293 CONDITION_SATISFIED indicates that <sync> was signaled before the
299 block, but simply tests the current state of <sync>. TIMEOUT_EXPIRED
300 will be returned in this case if <sync> is not signaled, even though
303 If <sync> is not the name of a sync object, an INVALID_VALUE error
309 void WaitSync(sync sync,bitfield flags,uint64 timeout)
312 returning to the application until <sync> is signaled, WaitSync
314 until <sync> is signaled [fn2].
319 from the client in anticipation of the sync being signaled,
322 <sync> has the same meaning as for ClientWaitSync.
330 the sync object being waited on was signaled.
337 If <sync> is not the name of a sync object, an INVALID_VALUE error
344 It is possible for both the GL client to be blocked on a sync object
347 commands to be queued in the GL server, all for a single sync
348 object. When such a sync object is signaled in this situation, the
353 See section D.2 for more information about blocking on a sync
359 A sync object can be in the signaled state only once the
360 corresponding fence command has completed and signaled the sync
363 If the sync object being blocked upon will not be signaled in finite
367 SYNC_FLUSH_COMMANDS_BIT bit is set in <flags>, and <sync> is
369 Flush will be performed before blocking on <sync>.
373 Applications which block on a fence sync object must take
378 If a sync object is marked for deletion while a client is blocking
381 deletion is deferred until the sync object is signaled and all
384 Additional constraints on the use of sync objects are discussed in
387 State must be maintained to indicate which sync object names are
388 currently in use. The state require for each sync object in use is
391 signaled or unsignaled. The initial values of sync object state are
418 6.1.6) describing sync object queries. Renumber existing subsection
423 Properties of sync objects may be queried using the command
425 void GetSynciv(sync sync,enum pname,sizei bufSize,sizei *length,
437 type of the sync object is placed in <values>. The only type
441 the sync object (SIGNALED or UNSIGNALED) is placed in <values>.
444 condition of the sync object is placed in <values>. The only
448 which the sync object was created is placed in <values>. No flags
451 If <sync> is not the name of a sync object, an INVALID_VALUE error
458 boolean IsSync(sync sync)
460 returns TRUE if <sync> is the name of a sync object. If <sync> is
461 not the name of a sync object, or if an error condition occurs,
462 IsSync returns FALSE (note that zero is not the name of a sync
467 sync object will not be deleted until it is no longer associated
473 In the first paragraph of the appendix, add "sync objects" to the
478 "D.1 Object Deletion Behavior (other than sync objects)
481 After a shared object (other than sync objects, discussed in section
486 D.1) describing sync object multicontext behavior. Renumber existing
496 Deleting sync objects is similar to other shared object types in
499 use. Unlike other shared object types, a sync object is determined
501 yet completed (signaling the sync object), or if there are any GL
502 clients and/or servers blocked on the sync object as a result of
504 commands have completed, a sync object has been signaled, and all
505 clients and/or servers blocked on that sync object have been
511 When multiple GL clients and/or servers are blocked on a single sync
512 object and that sync object is signaled, all such blocks are
529 sync object. The second method does not require a round trip to the
550 Contexts", of the OpenGL 3.1 Specification). If a sync object is
558 of a sync object are atomic. Also, a sync object will not be deleted
577 INVALID_VALUE is generated if the <sync> parameter of
579 of a sync object.
581 INVALID_VALUE is generated if the <sync> parameter of DeleteSync
582 is neither zero nor the name of a sync object.
603 OBJECT_TYPE Z_1 GetSynciv SYNC_FENCE Type of sync object 5.2
620 /* Place a fence and associate a fence sync object */
621 GLsync sync = glFenceSync(GLSYNC_GPU_COMMANDS_COMPLETE, 0);
623 /* Elsewhere, wait for the sync to be signaled */
629 glWaitSync(sync, 0, timeout);
636 glWaitSync(sync, 0, max_timeout);
640 1) Are sync objects shareable between multiple contexts?
642 RESOLVED: YES. The sync object namespace is shared, and sync
643 objects themselves may be shared or not. Shared sync objects can
646 Enabling multi-context aware sync objects is a major change from
648 because the rules defining sync object signaling behavior are
652 2) What specializations of sync objects are supported?
654 RESOLVED: Only fence sync objects (corresponding to synchronous
655 command stream fences). Additionally, fence sync objects are
657 initial status of a fence sync is unsignaled, and it may only be
660 We expect to define a way to map sync objects into OpenCL events
663 EGL sync objects (from the EGL_KHR_sync extension) should be
664 compatible with GL sync objects, although the sync object
665 namespace may require remapping between APIs. Also, EGL sync
670 The sync object framework is intended to generalize to other
671 types of sync objects, such as mappings of OS-specific events
672 and semaphores, new specializations of sync objects such as
673 "pulsed" sync objects associated with video retrace, or other
674 command stream conditions, such as sync objects which would be
678 3) What fence sync object conditions are supported?
699 effectively be done already, by explicitly signaling a sync
702 4) What state is associated with a sync object? Should state be
704 sync? This would express itself (for example) by passing a
707 RESOLVED: sync object state includes specialization (type),
713 as a timestamp when the sync object was last signaled, or a
715 terminology), for a sync object triggered by display retrace.
720 extension to create sync objects in a broader sharing domain
722 generic property list mechanism if a generic sync object
723 creation call is defined for multiple types of sync objects, but
724 for fence sync objects alone, the flags parameter is sufficient
727 6) Can sync objects and NV_fence fences share enumerants and/or the
728 namespace of fences / sync objects?
730 RESOLVED: NO. The sync object namespace cannot be the same as
732 list, while sync objects and their names are shared. We will
733 also not reuse enumerant values. The sync object interface is
754 8) What happens if you set a fence command for a sync object while a
759 command is associated with a fence sync object when it is
760 created. In the future we might reintroduce the separate sync
766 responsible for using sync objects and fences in ways that avoid
775 9) What happens to *WaitSyncs blocking on a sync object, and to an
776 associated fence command still pending execution, when the sync
779 RESOLVED: Following the OpenGL 3.0 shared object model, the sync
780 object name is immediately deleted, but the underlying sync
788 sync object?
790 RESOLVED: YES, since we support multi-context aware sync
792 same sync object. Additionally, multiple WaitSync commands may
796 11) Can we determine completion time of a sync object?
800 In the future, we may support variants of sync objects that
803 12) Can we block on multiple sync objects?
807 In the future, *WaitSyncs calls taking a list of sync object
809 returning an index/name of a sync object triggering the
819 14) Where can sync objects be waited on?
827 15) Can the specialization of sync objects be changed, once created?
832 making sync objects persistent (being able to reset their status
836 16) How can sync objects be used to facilitate asynchronous
841 performed in one thread associated with a sync. Another thread
842 finishes, tests for completion, or waits on that sync, depending
848 between the threads (so that the work thread knows when the sync
888 associate a sync object with them at the time they're issued,
894 17) Can the query object framework be used to support sync objects?
898 It is straightforward to map the sync object API onto queries,
901 makes it impossible to implement shared sync objects in the
905 It is also possible to map occlusion queries into the sync
909 18) Do *WaitSync wait on an event, or on sync object status? What is
910 the meaning of sync object status?
912 RESOLVED: *WaitSync blocks until the status of the sync object
919 constrained fence sync objects currently defined by this
923 R1) A sync object has two possible status values: signaled or
927 R2) When created, the state of the sync object is signaled by
930 R3) A fence command is inserted into a command stream. A sync
934 Fence(), the status of the sync object associated with that
937 R5) Multiple fence commands can be associated with the same sync
941 its associated sync object to the signaled state. The only
945 on a sync object, not on a fence.
947 R8) A wait function called on a sync object in the unsignaled
949 application") when the sync object transitions to the
955 if the sync object is in the signaled state. Note that
959 has been met, will set its associated sync object to the
960 signaled state. If the sync object is already in the
965 ClientWaitSync unblocks because the sync object it was
968 unblock once all (or any) of the sync objects passed to it
971 set the sync object in the signaled or unsignaled state.
972 This makes it easy for apps to reuse a sync object in the
973 multi-context case, so the sync object can be blocked upon
976 B6) We could define an API to convert a sync object into an OS
1003 but that's a bit weird - what if the sync object is already
1012 20) How can multi-context aware sync objects be used to synchronize
1017 context B must wait for the shared sync object to be
1021 showing specifically how to use sync objects and server waiting
1026 A: // Create a sync object in the unsignaled state
1056 has actually signaled a sync, due to timeout. Also, other sync
1061 23) How are sync objects implemented in terms of generic object
1068 24) Do we need a default sync object that is always present?
1069 (Notionally the "sync object named zero")?
1071 RESOLVED: NO. Fence sync objects cannot provide this
1073 use of (potentially client-created) sync object names.
1075 DISCUSSION: The use case for a default sync object is in
1081 on sync completion in B. But to do this, first we must have a
1082 sync object that is known to exist in both A and B, creating a
1087 1) Create a sync object in context A before forking another
1091 2) Punt to platform-specific code: create a sync object in A,
1094 sync is ready for use to coordinate object creation. This is
1098 shared sync object defined, which is present from context
1115 26) How will sync objects be linked to OpenCL events?
1118 type of sync object. A suggestion for that extension is
1121 sync object behaving like a fence sync, but with a different
1124 27) What is the relationship between EGL and OpenGL sync objects?
1127 APIs to a single underlying sync object implementation. It is
1128 unlikely that the namespaces of EGL and GL sync objects could be
1131 28) What is the deletion behavior of sync objects?
1179 names match the EGL sync object extension and consistency may be
1181 sync objects would have a use for conditions having nothing to
1182 do with fences, e.g. a display sync might have conditions
1187 GL sync objects, if anyone wants to make suggestions.
1191 RESOLVED: NO, not for fence sync objects. In the future other
1192 types of sync objects may choose to reintroduce this API.
1194 33) What is the datatype of a sync object handle?
1208 existing sync of type fence to rebind it to a new fence command, but
1209 it cannot be called on a non-fence sync. Expanded list of errors.
1213 Version 3, 2006/02/14 - Change FenceSync behavior to leave the sync
1215 in-flight when a fence sync is reset. Add a flags parameter to
1223 Version 4, 2006/02/22 - change sharing behavior so the sync
1224 namespace is shared, but sync objects can only be used from the
1226 C describing types of shared objects and how sharing affects sync
1230 distinction between waiting on events vs. waiting on changes in sync
1232 FenceSync into two parts to create the sync vs. issue the fence
1236 initial status value of the sync. Note that TestSync is polling the
1238 change. Make FinishSync return immediately if the status of the sync
1249 are outstanding for a sync (issue 9).
1255 Version 8, 2006/03/09 - A terminology change from "sync types" to
1256 "sync specializations" affects wording of several issues. Full
1258 set of rules defining sync signaling behavior (see issue 18). This
1261 complete, not the most recently issued one), 9 (sync destruction is
1264 issues 19-21 discussing additional ways to control sync signaling,
1265 and providing several examples of multi-context sync usage. Enum
1269 commands on a sync from different contexts may not be supported.
1270 Delaying sync destruction until there are no outstanding commands
1290 description of sync deletion for consistency with the description of
1292 8 and Appendix C that inserting fence commands on the same sync from
1299 several of the possible consequences) when a sync object being
1302 state". Changed sync status to SIGNALED/UNSIGNALED rather than
1305 describe full multi-context awareness. Use "sync object"
1306 consistently throughout and drop the "sync" shorthand. Use
1314 value returned from ClientWaitSync when the sync was signaled at
1319 model version of sync objects back into the GL2 API version for use
1322 those as the base of sync object manipulation. Move the object
1329 interfaces and the potential utility of a default sync object.
1334 generating sync names at creation time instead of using Gen*
1336 sync-specific GetSynciv instead of GetObjectiv. Specify that
1337 multiple waiters on a sync object are all released when it's
1341 Version 16, 2009/05/03 - Change Fence -> FenceSync and merge sync
1342 creation into the command, removing Sync (until other sync types are
1344 single fence sync object. Remove <where> parameter from WaitSync and
1359 INVALID_OPERATION when passing <sync> parameters that are not the
1360 names of sync objects. Remove leftover language saying that a bit of
1361 state is needed to specify if the sync is shared or not. Add
1372 saying we don't need a "default sync object".
1375 unresolved - none of them affect sync functionality, they are more
1379 * Use GLsync instead of GLuint for sync object handle type in all
1390 * Remove SignalSync, until a sync object type other than a fence
1391 sync is defined.