Name

    EXT_x11_sync_object

Name Strings

    GL_EXT_x11_sync_object

Contributors

    Piers Daniell
    Pierre-Loup Griffais
    James Jones
    Aaron Plattner

Contact

    James Jones, NVIDIA corporation (jajones 'at' nvidia.com)

Status

    Complete.

Version

    Last Modified Date: Jan 26, 2011
    Author Revision: 2

Number

    406

Dependencies

    OpenGL 3.2, or an earlier OpenGL version supporting the ARB_sync
    extension, is required.

    Written based on the wording of the OpenGL 3.2 specification.

    ARB_cl_event trivially affects the definition of this extension.

    This extension is only supported with contexts created on an X11
    display that supports the X Synchronization Extension version 3.1 or
    later.

Overview

    Synchronization objects added the ability to better coordinate
    operations between multiple GL command streams.  However, it is
    desirable to have the same level of coordination between GL
    command streams and external rendering APIs.  This extension
    introduces two new concepts to build upon the synchronization
    infrastructure provided by ARB_sync:

      1) A means to import an X Synchronization Fence object into the
         GL and use it as a sync object.

      2) The concept of a reusable sync object.

    The latter is necessary because the import operation is expensive
    and performing it every time a synchronization point was reached
    would make the synchronization prohibitively slow.

    This extension stops short of allowing the GL to change the state
    of imported/reusable sync objects, but does not add any language
    that would prohibit such functionality from being added in a
    subsequent extension.

New Procedures and Functions

    sync ImportSyncEXT(enum external_sync_type,
                       intptr external_sync,
                       bitfield flags);

New Types

    None

New Tokens

    Accepted by the <external_sync_type> parameter of
    ImportSyncEXT:

        SYNC_X11_FENCE_EXT                         0x90E1

Additions to Chapter 2 of the OpenGL 3.2 Specification (OpenGL
Operation)

    None

Additions to Chapter 3 of the OpenGL 3.2 Specification (Rasterization)

    None

Additions to Chapter 4 of the OpenGL 3.2 Specification (Per-Fragment
Operations and the Framebuffer)

    None

Additions to Chapter 5 of the OpenGL 3.2 Specification (Special
Functions)

  Modify Section 5.2 "Sync Objects and Fences" (p. 241)

  (Add after the seventh paragraph, p. 242)

    "Additional types of sync objects can be imported from external
    APIs. The command

        sync ImportSyncEXT(enum external_sync_type,
                           intptr external_sync,
                           bitfield flags);

    creates a GL sync object of the type <external_sync_type> based on
    the object referred to by <external_sync>.

    "<external_sync_type> must be SYNC_X11_FENCE_EXT, and
    <external_sync> must be the XID of a valid X11 Synchronization Fence
    object.  The status of the sync object returned will be SIGNALED
    when the X object is in the triggered state, or UNSIGNALED
    otherwise.

    "<flags> must be 0."

  (Replace the last sentence of paragraph 8, p. 242)

    "The initial property values for a sync object created by FenceSync
    or ImportSyncEXT are shown in tables 5.1 or 5.2 respectively.  A
    sync object created using ImportSyncEXT should hold a reference to
    any external resources needed to maintain the GL state associated
    with the GL object should the external object be destroyed."

  (Replace paragraph 9 with the following, p. 242)

    "If FenceSync or ImportSyncEXT fail to create a sync object, zero
    will be returned and a GL error will be generated as described. An
    INVALID_ENUM error is generated if <condition> is not
    SYNC_GPU_COMMANDS_COMPLETE or <external_sync_type> is not
    SYNC_X11_FENCE_EXT.  If <flags> is not zero, or if <external_sync>
    does not refer to a valid X Synchronization Fence object, an
    INVALID_VALUE error is generated.

    "However, implementations are not required to validate
    <external_sync>, and passing an invalid external sync object handle
    may result in undefined behavior up to and including program
    termination."

  (Add table 5.2 immediately following table 5.1, p. 243)

    Property Name             Property Value
    ------------------------  -------------------------------------
    OBJECT_TYPE               <external_sync_type>
    SYNC_CONDITION            NONE
    SYNC_STATUS               dependent on state of <external_sync>
    SYNC_FLAGS                <flags>

    Table 5.2: Initial properties of a sync object created with
    ImportSyncEXT.

  (Replace paragraph 12 with the following, p. 243)

    "If <sync> is in the signaled state, or if no ClientWaitSync or
    WaitSync commands are blocking on <sync>, the object is deleted
    immediately.  Otherwise, <sync> is flagged for deletion and will be
    deleted when it reaches the signaled state and is no longer blocking
    any ClientWaitSync or WaitSync command.  In either case, after
    returning from DeleteSync the <sync> name is invalid and can no
    longer be used to refer to the sync object.

  Modify section 5.2.2 "Signaling" (p. 245)

  (Replace the first paragraph with the following, p. 245)

    "A sync object enters the signaled state only once the corresponding
    fence command has completed and signaled the sync object, or the
    external sync object associated with it has reached a state
    corresponding to the GL signaled state as described in table 5.3."

  (Add table 5.3)

    OBJECT_TYPE         External state corresponding to GL signaled state
    ------------------  -------------------------------------------------
    SYNC_X11_FENCE_EXT  triggered

  (Replace the last sentence of the last paragraph with the following,
  p. 246)

    "Additionally, sync objects linked to external sync objects require
    implementation-specific, non-queriable internal state uniquely
    identifying the external object.  The initial values of sync object
    state are defined as specified by FenceSync and ImportSyncEXT."

Additions to Chapter 6 of the OpenGL 3.2 Specification (State and State
Requests)

  Modify section 6.1.7 "Sync Object State" (p. 256)

  (Replace the last sentence of paragraph 4 with the following, p. 256)

    "The only types supported are SYNC_FENCE and SYNC_X11_FENCE_EXT."

Additions to Appendix D of the OpenGL 3.2 Specification (Shared Objects
and Multiple Contexts)

  Modify section D.1.2 "Deleted Object and Object Name Lifetimes"
  (p. 324)

  Replace sentence 3 in the first paragraph with the following, (p. 324)

    "A sync object is in use while it is not in the signaled state, or
    while there are any GL clients and/or servers blocked on the sync
    object as a result of ClientWaitSync or WaitSync commands."

GLX Protocol

    TBD

Dependencies on ARB_sync

    ARB_sync or GL version 3.2 or above are required to implement this
    extension.

Dependencies on ARB_cl_event

    If ARB_cl_event is present, the language of the two specs must be
    merged.  There should be no technical conflicts, but the actual
    text modifications overlap.

Errors

    The error INVALID_ENUM is generated if ImportSyncEXT is called
    where <external_sync_type> is not SYNC_X11_FENCE_EXT.

    The error INVALID_VALUE is generated if ImportSyncEXT is called
    where <external_sync> does not refer to a valid X11 Synchronization
    Fence object.

    The error INVALID_VALUE is generated if ImportSyncEXT is called
    where <flags> is not 0.

New State

    None

Issues

    1) Should the import command be a generic entry point, or
    specialized for X11 sync fence objects?

      RESOLVED: A generic command is used.  This command can be reused
      by future extensions to import other sync types.  It takes a
      pointer-sized parameter that can be used to import any type of
      synchronization object.  Objects that require more than one
      value to uniquely identify them, e.g. OpenCL events, can define
      an intermediate structure that contains all required values and
      then pass in a pointer to the structure.

    2) What happens if the X11 sync object is destroyed while the GL
    sync object referencing it is still in use?

      RESOLVED: The GL object should hold a reference on any resources
      needed to continue using the sync object until the GL object is
      deleted.

Revision History

    Date: 26-Jan-2011
    Revision: 2 (James Jones)
       - Renamed from EXT_x_sync_object to EXT_x11_sync_object.
       - Added issues 1 and 2 and related spec language.
       - Added language describing when external syncs are signaled.
       - Added language describing when external syncs are deleted.

    Date: 20-Jan-2011
    Revision: 1 (James Jones)
      - Initial Revision.