Khronos Public Bugzilla
Bug 1071 - 4.1 Clarify the relation between S/W and H/W to resolve apparent deadlock
Summary: 4.1 Clarify the relation between S/W and H/W to resolve apparent deadlock
Alias: None
Product: OpenGL
Classification: Unclassified
Component: API Specification (show other bugs)
Version: unspecified
Hardware: PC Linux
: P3 major
Target Milestone: ---
Assignee: Jon Leech
QA Contact: ARB Next Generation API TSG email alias
Depends on:
Reported: 2013-12-15 10:43 PST by Cedric
Modified: 2018-01-25 00:15 PST (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Cedric 2013-12-15 10:43:08 PST
The specification suggests that there are "events" which signal sync objects. It also states that the "server" (it should also be made clearer what is meant by that term) waits on WaitSync( ) until a sync is signalled (i.e. the according event has occured) (4.1.1).

Section 4.1 only makes sense (and can agree with 2.1 "commands are executed in the order in which they are issued) if its made explicit that

1) The "execution" of a FenceSync is defined to be the insertion of the fence into the command queue (the "execution" is *not* the fence being triggered)

2) The "waiting of the server" as by "WaitSync" ought to be clearly defined as the GL SOFTWARE not issueing further instructions to the HARDWARE until the HARDWARE has performed all operations associated to the commands which were passed to the SOFTWARE before that point.

Otherwise, if we simply speak of the GL ("the server") taking commands and then "waiting" for a fence, imagine the following situation: The client issues the following commands

a( ); b( ); c( ); FenceSync( ); d( ); e( ); f( ); WaitSync( )

and the server starts processing them. At the time when "WaitSync is called", a( ) and b( ) have finished. IF THE SPECIFICATION WAS RIGHT, the server would now wait at c( ) for the FenceSync( ) to be reached. This will obviously deadlock the server!
Comment 1 Piers Daniell 2015-11-05 12:33:22 PST
In the example you gave:
a( ); b( ); c( ); FenceSync( ); d( ); e( ); f( ); WaitSync( )

the server (or GPU) would execute each of those commands in sequence. Since the WaitSync() comes at the end, there won't be a deadlock since by the time it gets there it's already executed the FenceSync().

These sync objects are useful when the FenceSync() and WaitSync() are executed by different GL contexts to synchronize one context with the other.

If you need to synchronize the app with the GPU then ClientWaitSync() can be used.
Comment 2 Jon Leech 2018-01-25 00:15:20 PST
Hopefully Piers' comment addressed the problem.