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
Status: NEW
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: 2013-12-15 10:43 PST (History)
0 users

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!