api/glossary.asciidoc

// Copyright 2017-2024 The Khronos Group Inc.
// SPDX-License-Identifier: CC-BY-4.0

// [glossary] // MK:Don't enable [glossary] - prevents chapter numbering.
= Glossary

Application ::
    The combination of the program running on the host and OpenCL devices.

Acquire semantics ::
    One of the memory order semantics defined for synchronization
    operations.
    Acquire semantics apply to atomic operations that load from memory.
    Given two units of execution, *A* and *B*, acting on a shared atomic
    object *M*, if *A* uses an atomic load of *M* with acquire semantics to
    synchronize-with an atomic store to *M* by *B* that used release
    semantics, then *A*'s atomic load will occur before any subsequent
    operations by *A*.
    Note that the memory orders _release_, _sequentially consistent_, and
    _acquire_release_ all include _release semantics_ and effectively pair
    with a load using acquire semantics.

Acquire release semantics ::
    A memory order semantics for synchronization operations (such as atomic
    operations) that has the properties of both acquire and release memory
    orders.
    It is used with read-modify-write operations.

Atomic operations ::
    Operations that at any point, and from any perspective, have either
    occurred completely, or not at all.
    Memory orders associated with atomic operations may constrain the
    visibility of loads and stores with respect to the atomic operations
    (see _relaxed semantics_, _acquire semantics_, _release semantics_ or
    _acquire release semantics_).

Blocking and Non-Blocking Enqueue API calls ::
    A _non-blocking enqueue API call_ places a _command_ on a
    _command-queue_ and returns immediately to the host.
    The _blocking-mode enqueue API calls_ do not return to the host until
    the command has completed.

Barrier ::
    There are three types of _barriers_ a command-queue barrier, a
    work-group barrier, and a sub-group barrier.
+
--
  * The OpenCL API provides a function to enqueue a _command-queue_
    _barrier_ command.
    This _barrier_ command ensures that all previously enqueued commands to
    a command-queue have finished execution before any following _commands_
    enqueued in the _command-queue_ can begin execution.
  * The OpenCL kernel execution model provides built-in _work-group barrier_
    functionality.
    This _barrier_ built-in function can be used by a _kernel_ executing on
    a _device_ to perform synchronization between _work-items_ in a
    _work-group_ executing the _kernel_.
    All the _work-items_ of a _work-group_ must execute the _barrier_
    construct before any are allowed to continue execution beyond the
    _barrier_.
  * The OpenCL kernel execution model provides built-in _sub-group barrier_
    functionality.
    This _barrier_ built-in function can be used by a _kernel_ executing on
    a _device_ to perform synchronization between _work-items_ in a
    _sub-group_ executing the _kernel_.
    All the _work-items_ of a _sub-group_ must execute the _barrier_
    construct before any are allowed to continue execution beyond the
    _barrier_.
--

Buffer Object ::
    A memory object that stores a linear collection of bytes.
    Buffer objects are accessible using a pointer in a _kernel_ executing on
    a _device_.
    Buffer objects can be manipulated by the host using OpenCL API calls.
    A _buffer object_ encapsulates the following information:
+
--
  * Size in bytes.
  * Properties that describe usage information and which region to allocate
    from.
  * Buffer data.
--

Built-in Kernel ::
    A _built-in kernel_ is a _kernel_ that is executed on an OpenCL _device_
    or _custom device_ by fixed-function hardware or in firmware.
    _Applications_ can query the _built-in kernels_ supported by a _device_
    or _custom device_.
    A _program object_ can only contain _kernels_ written in OpenCL C or
    _built-in kernels_ but not both.
    See also _Kernel_ and _Program_.

Child kernel ::
    See _Device-side enqueue_.

Command ::
    The OpenCL operations that are submitted to a _command-queue_ for
    execution.
    For example, OpenCL commands issue kernels for execution on a compute
    device, manipulate memory objects, etc.

Command-queue ::
    An object that holds _commands_ that will be executed on a specific
    _device_.
    The _command-queue_ is created on a specific _device_ in a _context_.
    _Commands_ to a _command-queue_ are queued in-order but may be executed
    in-order or out-of-order.
    Refer to _In-order Execution_ and _Out-of-order Execution_.

Command-queue Barrier ::
    See _Barrier_.

Command synchronization ::
    Constraints on the order that commands are launched for execution on a
    device defined in terms of the synchronization points that occur between
    commands in host command-queues and between commands in device-side
    command-queues.
    See _synchronization points_.

Complete ::
    The final state in the six state model for the execution of a command.
    The transition into this state occurs is signaled through event objects
    or callback functions associated with a command.

Compute Device Memory ::
    This refers to one or more memories attached to the compute device.

Compute Unit ::
    An OpenCL _device_ has one or more _compute units_.
    A _work-group_ executes on a single _compute unit_.
    A _compute unit_ is composed of one or more _processing elements_ and
    _local memory_.
    A _compute unit_ may also include dedicated texture filter units that
    can be accessed by its processing elements.

Concurrency ::
    A property of a system in which a set of tasks in a system can remain
    active and make progress at the same time.
    To utilize concurrent execution when running a program, a programmer
    must identify the concurrency in their problem, expose it within the
    source code, and then exploit it using a notation that supports
    concurrency.

Constant Memory ::
    A region of _global memory_ that remains constant during the execution
    of a _kernel_.
    The _host_ allocates and initializes memory objects placed into
    _constant memory_.

Context ::
    The environment within which the kernels execute and the domain in which
    synchronization and memory management is defined.
    The _context_ includes a set of _devices_, the memory accessible to
    those _devices_, the corresponding memory properties and one or more
    _command-queues_ used to schedule execution of a _kernel(s)_ or
    operations on _memory objects_.

Control flow ::
    The flow of instructions executed by a work-item.
    Multiple logically related work-items may or may not execute the same
    control flow.
    The control flow is said to be _converged_ if all the work-items in the
    set execution the same stream of instructions.
    In a _diverged_ control flow, the work-items in the set execute
    different instructions.
    At a later point, if a diverged control flow becomes converged, it is
    said to be a re-converged control flow.

Converged control flow ::
    See _Control flow_.

Custom Device ::
    An OpenCL _device_ that fully implements the OpenCL Runtime but does not
    support _programs_ written in OpenCL C.
    A custom device may be specialized non-programmable hardware that is
    very power efficient and performant for directed tasks or hardware with
    limited programmable capabilities such as specialized DSPs.
    Custom devices are not OpenCL conformant.
    Custom devices may support an online compiler.
    Programs for custom devices can be created using the OpenCL runtime APIs
    that allow OpenCL programs to be created from source (if an online
    compiler is supported) and/or binary, or from _built-in kernels_
    supported by the _device_.
    See also _Device_.

Data Parallel Programming Model ::
    Traditionally, this term refers to a programming model where concurrency
    is expressed as instructions from a single program applied to multiple
    elements within a set of data structures.
    The term has been generalized in OpenCL to refer to a model wherein a
    set of instructions from a single program are applied concurrently to
    each point within an abstract domain of indices.

Data race ::
    The execution of a program contains a data race if it contains two
    actions in different work-items or host threads where (1) one action
    modifies a memory location and the other action reads or modifies the
    same memory location, and (2) at least one of these actions is not
    atomic, or the corresponding memory scopes are not inclusive, and (3)
    the actions are global actions unordered by the global-happens-before
    relation or are local actions unordered by the local-happens-before
    relation.

Deprecation ::
    Existing features are marked as deprecated if their usage is not
    recommended as that feature is being de-emphasized, superseded and may
    be removed from a future version of the specification.

Device ::
    A _device_ is a collection of _compute units_.
    A _command-queue_ is used to queue _commands_ to a _device_.
    Examples of _commands_ include executing _kernels_, or reading and
    writing _memory objects_.
    OpenCL devices typically correspond to a GPU, a multi-core CPU, and
    other processors such as DSPs and the Cell/B.E.
    processor.

Device-side enqueue ::
    A mechanism whereby a kernel-instance is enqueued by a kernel-instance
    running on a device without direct involvement by the host program.
    This produces _nested parallelism_; i.e. additional levels of
    concurrency are nested inside a running kernel-instance.
    The kernel-instance executing on a device (the _parent kernel_) enqueues
    a kernel-instance (the _child kernel_) to a device-side command-queue.
    Child and parent kernels execute asynchronously though a parent kernel
    does not complete until all of its child-kernels have completed.

Diverged control flow ::
    See _Control flow_.

Ended ::
    The fifth state in the six state model for the execution of a command.
    The transition into this state occurs when execution of a command has
    ended.
    When a Kernel-enqueue command ends, all of the work-groups associated
    with that command have finished their execution.

Event Object ::
    An _event object_ encapsulates the status of an operation such as a
    _command_.
    It can be used to synchronize operations in a context.

Event Wait List ::
    An _event wait list_ is a list of _event objects_ that can be used to
    control when a particular _command_ begins execution.

Fence ::
    A memory ordering operation without an associated atomic object.
    A fence can use the _acquire semantics, release semantics_, or _acquire
    release semantics_.

Framework ::
    A software system that contains the set of components to support
    software development and execution.
    A _framework_ typically includes libraries, APIs, runtime systems,
    compilers, etc.

Generic address space ::
    An address space that include the _private_, _local_, and _global_
    address spaces available to a device.
    The generic address space supports conversion of pointers to and from
    private, local and global address spaces, and hence lets a programmer
    write a single function that at compile time can take arguments from any
    of the three named address spaces.

Global-happens-before ::
    See _Happens-before_.

Global ID ::
    A _global ID_ is used to uniquely identify a _work-item_ and is derived
    from the number of _global work-items_ specified when executing a
    _kernel_.
    The _global ID_ is a N-dimensional value that starts at (0, 0, ... 0).
    See also _Local ID_.

Global Memory ::
    A memory region accessible to all _work-items_ executing in a _context_.
    It is accessible to the _host_ using _commands_ such as read, write and
    map.
    _Global memory_ is included within the _generic address space_ that
    includes the private and local address spaces.

GL share group ::
    A _GL share group_ object manages shared OpenGL or OpenGL ES resources
    such as textures, buffers, framebuffers, and renderbuffers and is
    associated with one or more GL context objects.
    The _GL share group_ is typically an opaque object and not directly
    accessible.

Handle ::
    An opaque type that references an _object_ allocated by OpenCL.
    Any operation on an _object_ occurs by reference to that object's handle.
    Each object must have a unique handle value during the course of its
    lifetime. Handle values may be, but are not required to be, re-used by
    an implementation.

Happens-before ::
    An ordering relationship between operations that execute on multiple
    units of execution.
    If an operation A happens-before operation B then A must occur before B;
    in particular, any value written by A will be visible to B.
    We define two separate happens-before relations: _global-happens-before_
    and _local-happens-before_.
    These are defined in <<memory-ordering-rules, Memory Ordering Rules>>.

Host ::
    The _host_ interacts with the _context_ using the OpenCL API.

Host-thread ::
    The unit of execution that executes the statements in the host program.

Host pointer ::
    A pointer to memory that is in the virtual address space on the _host_.

Illegal ::
    Behavior of a system that is explicitly not allowed and will be reported
    as an error when encountered by OpenCL.

Image Object ::
    A _memory object_ that stores a two- or three-dimensional structured
    array.
    Image data can only be accessed with read and write functions.
    The read functions use a _sampler_.
+
--
The _image object_ encapsulates the following information:

  * Dimensions of the image.
  * Description of each element in the image.
  * Properties that describe usage information and which region to allocate
    from.
  * Image data.

The elements of an image are selected from a list of predefined image
formats.
--

Implementation-Defined ::
    Behavior that is explicitly allowed to vary between conforming
    implementations of OpenCL.
    An OpenCL implementor is required to document the implementation-defined
    behavior.

Independent Forward Progress ::
    If an entity supports independent forward progress, then if it is
    otherwise not dependent on any actions due to be performed by any other
    entity (for example it does not wait on a lock held by, and thus that
    must be released by, any other entity), then its execution cannot be
    blocked by the execution of any other entity in the system (it will not
    be starved).
    Work-items in a sub-group, for example, typically do not support
    independent forward progress, so one work-item in a sub-group may be
    completely blocked (starved) if a different work-item in the same
    sub-group enters a spin loop.

In-order Execution ::
    A model of execution in OpenCL where the _commands_ in a _command-queue_
    are executed in order of submission with each _command_ running to
    completion before the next one begins.
    See _Out-of-order Execution_.

Intermediate Language ::
    A lower-level language that may be used to create programs.
    SPIR-V is a required intermediate language (IL) for OpenCL 2.1 and 2.2 devices.
    Other OpenCL devices may optionally support SPIR-V or other ILs.

Kernel ::
    A _kernel_ is a function declared in a _program_ and executed on an
    OpenCL _device_.
    A _kernel_ is identified by the `+__kernel+` or `kernel` qualifier applied to
    any function defined in a _program_.

Kernel-instance ::
    The work carried out by an OpenCL program occurs through the execution
    of kernel-instances on devices.
    The kernel instance is the _kernel object_, the values associated with
    the arguments to the kernel, and the parameters that define the
    _ND-range_ index space.

Kernel Object ::
    A _kernel object_ encapsulates a specific _kernel_ function declared
    in a _program_ and the argument values to be used when executing this
    _kernel_ function.

Kernel Language ::
    A language that is used to represent source code for kernel.
    Kernels may be directly created from OpenCL C kernel language
    source strings.
    Other kernel languages may be supported by compiling to SPIR-V,
    another supported Intermediate Language, or to a device-specific
    program binary format.

Launch ::
    The transition of a command from the _submitted_ state to the _ready_
    state.
    See _Ready_.

Local ID ::
    A _local ID_ specifies a unique _work-item ID_ within a given
    _work-group_ that is executing a _kernel_.
    The _local ID_ is a N-dimensional value that starts at (0, 0, ... 0).
    See also _Global ID_.

Local Memory ::
    A memory region associated with a _work-group_ and accessible only by
    _work-items_ in that _work-group_.
    _Local memory_ is included within the _generic address space_ that
    includes the private and global address spaces.

Marker ::
    A _command_ queued in a _command-queue_ that can be used to tag all
    _commands_ queued before the _marker_ in the _command-queue_.
    The _marker_ command returns an _event_ which can be used by the
    _application_ to queue a wait on the marker event i.e. wait for all
    commands queued before the _marker_ command to complete.

Memory Consistency Model ::
    Rules that define which values are observed when multiple units of
    execution load data from any shared memory plus the synchronization
    operations that constrain the order of memory operations and define
    synchronization relationships.
    The memory consistency model in OpenCL is based on the memory model from
    the ISO C11 programming language.

Memory Objects ::
    A _memory object_ is a handle to a reference counted region of _Global
    Memory_.
    Also see _Buffer Object_ and _Image Object_.

Memory Regions (or Pools) ::
    A distinct address space in OpenCL.
    _Memory regions_ may overlap in physical memory though OpenCL will treat
    them as logically distinct.
    The _memory regions_ are denoted as _private_, _local_, _constant,_ and
    _global_.

Memory Scopes ::
    These memory scopes define a hierarchy of visibilities when analyzing
    the ordering constraints of memory operations.
    They are defined by the values of the *memory_scope* enumeration
    constant.
    Current values are *memory_scope_work_item* (memory constraints only
    apply to a single work-item and in practice apply only to image
    operations), *memory_scope_sub_group* (memory-ordering constraints only
    apply to work-items executing in a sub-group), *memory_scope_work_group*
    (memory-ordering constraints only apply to work-items executing in a
    work-group), *memory_scope_device* (memory-ordering constraints only
    apply to work-items executing on a single device) and
    *memory_scope_all_svm_devices* or equivalently *memory_scope_all_devices*
    (memory-ordering constraints only apply to work-items executing across
    multiple devices and when using shared virtual memory).

Modification Order ::
    All modifications to a particular atomic object M occur in some
    particular _total order_, called the _modification order_ of M.
    If A and B are modifications of an atomic object M, and A happens-before
    B, then A shall precede B in the modification order of M.
    Note that the modification order of an atomic object M is independent of
    whether M is in local or global memory.

Nested Parallelism ::
    See _device-side enqueue_.

Object ::
    Objects are abstract representation of the resources that can be
    manipulated by the OpenCL API.
    Examples include _program objects_, _kernel objects_, and _memory
    objects_.

Out-of-order Execution ::
    A model of execution in which _commands_ placed in the _work queue_ may
    begin and complete execution in any order consistent with constraints
    imposed by _event wait lists_and_command-queue barrier_.
    See _In-order Execution_.

Parent device ::
    The OpenCL _device_ which is partitioned to create _sub-devices_.
    Not all _parent devices_ are _root devices_.
    A _root device_ might be partitioned and the _sub-devices_ partitioned
    again.
    In this case, the first set of _sub-devices_ would be _parent devices_
    of the second set, but not the _root devices_.
    Also see _Device_, _parent device_ and _root device_.

Parent kernel ::
    see _Device-side enqueue_.

Pipe ::
    The _pipe_ memory object conceptually is an ordered sequence of data
    items.
    A pipe has two endpoints: a write endpoint into which data items are
    inserted, and a read endpoint from which data items are removed.
    At any one time, only one kernel instance may write into a pipe, and
    only one kernel instance may read from a pipe.
    To support the producer consumer design pattern, one kernel instance
    connects to the write endpoint (the producer) while another kernel
    instance connects to the reading endpoint (the consumer).

Platform ::
    The _host_ plus a collection of _devices_ managed by the OpenCL
    _framework_ that allow an application to share _resources_ and execute
    _kernels_ on _devices_ in the _platform_.

Private Memory ::
    A region of memory private to a _work-item_.
    Variables defined in one _work-items_ _private memory_ are not visible
    to another _work-item_.

Processing Element ::
    A virtual scalar processor.
    A work-item may execute on one or more processing elements.

Program ::
    An OpenCL _program_ consists of a set of _kernels_.
    _Programs_ may also contain auxiliary functions called by the
    _kernel_ functions and constant data.

Program Object ::
    A _program object_ encapsulates the following information:
+
--
  * A reference to an associated _context_.
  * A _program_ source or binary.
  * The latest successfully built program executable, the list of _devices_
    for which the program executable is built, the build options used and a
    build log.
  * The number of _kernel objects_ currently attached.
--

Queued ::
    The first state in the six state model for the execution of a command.
    The transition into this state occurs when the command is enqueued into
    a command-queue.

Ready ::
    The third state in the six state model for the execution of a command.
    The transition into this state occurs when pre-requisites constraining
    execution of a command have been met; i.e. the command has been
    launched.
    When a kernel-enqueue command is launched, work-groups associated with
    the command are placed in a devices work-pool from which they are
    scheduled for execution.

Re-converged Control Flow ::
    see _Control flow_.

Reference Count ::
    The life span of an OpenCL object is determined by its _reference
    count_, an internal count of the number of references to the object.
    When you create an object in OpenCL, its _reference count_ is set to
    one.
    Subsequent calls to the appropriate _retain_ API (such as
    {clRetainContext}, {clRetainCommandQueue}) increment the _reference
    count_.
    Calls to the appropriate _release_ API (such as {clReleaseContext},
    {clReleaseCommandQueue}) decrement the _reference count_.
    Implementations may also modify the _reference count_, e.g. to track
    attached objects or to ensure correct operation of in-progress or
    scheduled activities.
    The object becomes inaccessible to host code when the number of
    _release_ operations performed matches the number of _retain_ operations
    plus the allocation of the object.
    At this point the reference count may be zero but this is not
    guaranteed.

Relaxed Consistency ::
    A memory consistency model in which the contents of memory visible to
    different _work-items_ or _commands_ may be different except at a
    _barrier_ or other explicit synchronization points.

Relaxed Semantics ::
    A memory order semantics for atomic operations that implies no order
    constraints.
    The operation is _atomic_ but it has no impact on the order of memory
    operations.

Release Semantics ::
    One of the memory order semantics defined for synchronization
    operations.
    Release semantics apply to atomic operations that store to memory.
    Given two units of execution, *A* and *B*, acting on a shared atomic
    object *M*, if *A* uses an atomic store of *M* with release semantics to
    synchronize-with an atomic load to *M* by *B* that used acquire
    semantics, then *A*'s atomic store will occur _after_ any prior
    operations by *A*.
    Note that the memory orders _acquire_, _sequentially consistent_, and
    _acquire_release_ all include _acquire semantics_ and effectively pair
    with a store using release semantics.

Remainder work-groups ::
    When the work-groups associated with a kernel-instance are defined, the
    sizes of a work-group in each dimension may not evenly divide the size
    of the ND-range in the corresponding dimensions.
    The result is a collection of work-groups on the boundaries of the
    ND-range that are smaller than the base work-group size.
    These are known as _remainder work-groups_.

Running ::
    The fourth state in the six state model for the execution of a command.
    The transition into this state occurs when the execution of the command
    starts.
    When a Kernel-enqueue command starts, one or more work-groups associated
    with the command start to execute.

Root device ::
    A _root device_ is an OpenCL _device_ that has not been partitioned.
    Also see _Device_, _Parent device_ and _Root device_.

Resource ::
    A class of _objects_ defined by OpenCL.
    An instance of a _resource_ is an _object_.
    The most common _resources_ are the _context_, _command-queue_, _program
    objects_, _kernel objects_, and _memory objects_.
    Computational resources are hardware elements that participate in the
    action of advancing a program counter.
    Examples include the _host_, _devices_, _compute units_ and _processing
    elements_.

Retain, Release ::
    The action of incrementing (retain) and decrementing (release) the
    reference count using an OpenCL _object_.
    This is a book keeping functionality to make sure the system doesn't
    remove an _object_ before all instances that use this _object_ have
    finished.
    Refer to _Reference Count_.

Sampler ::
    An _object_ that describes how to sample an image when the image is read
    in the _kernel_.
    The image read functions take a _sampler_ as an argument.
    The _sampler_ specifies the image addressing-mode i.e. how out-of-range
    image coordinates are handled, the filter mode, and whether the input
    image coordinate is a normalized or unnormalized value.

Scope inclusion ::
    Two actions *A* and *B* are defined to have an inclusive scope if they
    have the same scope *P* such that: (1) if *P* is
    *memory_scope_sub_group*, and *A* and *B* are executed by work-items
    within the same sub-group, or (2) if *P* is *memory_scope_work_group*,
    and *A* and *B* are executed by work-items within the same work-group,
    or (3) if *P* is *memory_scope_device*, and *A* and *B* are executed by
    work-items on the same device, or (4) if *P* is
    *memory_scope_all_svm_devices* or *memory_scope_all_devices*, if *A* and *B*
    are executed by host threads or by work-items on one or more devices that
    can share SVM memory with each other and the host process.

Sequenced before ::
    A relation between evaluations executed by a single unit of execution.
    Sequenced-before is an asymmetric, transitive, pair-wise relation that
    induces a partial order between evaluations.
    Given any two evaluations A and B, if A is sequenced-before B, then the
    execution of A shall precede the execution of B.

Sequential consistency ::
    Sequential consistency interleaves the steps executed by each unit of
    execution.
    Each access to a memory location sees the last assignment to that
    location in that interleaving.

Sequentially consistent semantics ::
    One of the memory order semantics defined for synchronization
    operations.
    When using sequentially-consistent synchronization operations, the loads
    and stores within one unit of execution appear to execute in program
    order (i.e., the sequenced-before order), and loads and stores from
    different units of execution appear to be simply interleaved.

Shared Virtual Memory (SVM) ::
    An address space exposed to both the host and the devices within a
    context.
    SVM causes addresses to be meaningful between the host and all of the
    devices within a context and therefore supports the use of pointer based
    data structures in OpenCL kernels.
    It logically extends a portion of the global memory into the host
    address space therefore giving work-items access to the host address
    space.
    There are three types of SVM in OpenCL:
+
--
_Coarse-Grained buffer SVM_ ::
    Sharing occurs at the granularity of regions of OpenCL buffer memory
    objects.
_Fine-Grained buffer SVM_ ::
    Sharing occurs at the granularity of individual loads/stores into bytes
    within OpenCL buffer memory objects.
_Fine-Grained system SVM_ ::
    Sharing occurs at the granularity of individual loads/stores into bytes
    occurring anywhere within the host memory.
--

SIMD ::
    Single Instruction Multiple Data.
    A programming model where a _kernel_ is executed concurrently on
    multiple _processing elements_ each with its own data and a shared
    program counter.
    All _processing elements_ execute a strictly identical set of
    instructions.

Specialization constants ::
    Specialization constants are special constant objects that do not
    have known constant values in an intermediate language (e.g. SPIR-V).
    Applications may provide updated values for the specialization constants
    before a program is built.
    Specialization constants that do not receive a value from an application
    shall use the default specialization constant value.

SPMD ::
    Single Program Multiple Data.
    A programming model where a _kernel_ is executed concurrently on
    multiple _processing elements_ each with its own data and its own
    program counter.
    Hence, while all computational resources run the same _kernel_ they
    maintain their own instruction counter and due to branches in a
    _kernel_, the actual sequence of instructions can be quite different
    across the set of _processing elements_.

Sub-device ::
    An OpenCL _device_ can be partitioned into multiple _sub-devices_.
    The new _sub-devices_ alias specific collections of compute units within
    the parent _device_, according to a partition scheme.
    The _sub-devices_ may be used in any situation that their parent
    _device_ may be used.
    Partitioning a _device_ does not destroy the parent _device_, which may
    continue to be used along side and intermingled with its child
    _sub-devices_.
    Also see _Device_, _Parent device_ and _Root device_.

Sub-group ::
    Sub-groups are an implementation-dependent grouping of work-items within
    a work-group.
    The size and number of sub-groups is implementation-defined.

Sub-group Barrier ::
    See _Barrier_.

Submitted ::
    The second state in the six state model for the execution of a command.
    The transition into this state occurs when the command is flushed from
    the command-queue and submitted for execution on the device.
    Once submitted, a programmer can assume a command will execute once its
    prerequisites have been met.

SVM Buffer ::
    A memory allocation enabled to work with _Shared Virtual Memory (SVM)_.
    Depending on how the SVM buffer is created, it can be a coarse-grained
    or fine-grained SVM buffer.
    Optionally it may be wrapped by a _Buffer Object_.
    See _Shared Virtual Memory (SVM)_.

Synchronization ::
    Synchronization refers to mechanisms that constrain the order of
    execution and the visibility of memory operations between two or more
    units of execution.

Synchronization operations ::
    Operations that define memory order constraints in a program.
    They play a special role in controlling how memory operations in one
    unit of execution (such as work-items or, when using SVM a host thread)
    are made visible to another.
    Synchronization operations in OpenCL include _atomic operations_ and
    _fences_.

Synchronization point ::
    A synchronization point between a pair of commands (A and B) assures
    that results of command A happens-before command B is launched (i.e.
    enters the ready state) .

Synchronizes with ::
    A relation between operations in two different units of execution that
    defines a memory order constraint in global memory
    (_global-synchronizes-with_) or local memory
    (_local-synchronizes-with_).

Task Parallel Programming Model ::
    A programming model in which computations are expressed in terms of
    multiple concurrent tasks executing in one or more _command-queues_.
    The concurrent tasks can be running different _kernels_.

Thread-safe ::
    An OpenCL API call is considered to be _thread-safe_ if the internal
    state as managed by OpenCL remains consistent when called simultaneously
    by multiple _host_ threads.
    OpenCL API calls that are _thread-safe_ allow an application to call
    these functions in multiple _host_ threads without having to implement
    mutual exclusion across these _host_ threads i.e. they are also
    re-entrant-safe.

Undefined ::
    The behavior of an OpenCL API call, built-in function used inside a
    _kernel_ or execution of a _kernel_ that is explicitly not defined by
    OpenCL.
    A conforming implementation is not required to specify what occurs when
    an undefined construct is encountered in OpenCL.

Unit of execution ::
    A generic term for a process, OS managed thread running on the host (a
    host-thread), kernel-instance, host program, work-item or any other
    executable agent that advances the work associated with a program.

[[valid-object-definition]]
Valid Object ::
    An OpenCL object is considered valid if it meets all of the following
    criteria:
+
--
  * The object was created by a successful call to an OpenCL API function.
  * The object has a strictly positive application-owned reference count.
  * The object has not had its backing memory changed outside of normal
    usage by the OpenCL implementation (e.g. corrupted by the application, a
    library it uses, the implementation itself, or any other agent that can
    access the object's backing memory).

An object is only valid in the platform where it was created.

An OpenCL implementation must check for a `NULL` object to determine if an
object is valid.  The behavior for all other invalid objects is
implementation-defined.
--

Work-group ::
    A collection of related _work-items_ that execute on a single _compute
    unit_.
    The _work-items_ in the group execute the same _kernel-instance_ and
    share _local_ _memory_ and _work-group functions_.

Work-group Barrier ::
    See _Barrier_.

Work-group Function ::
    A function that carries out collective operations across all the
    work-items in a work-group.
    Available collective operations are a barrier, reduction, broadcast,
    prefix sum, and evaluation of a predicate.
    A work-group function must occur within a _converged control flow_; i.e.
    all work-items in the work-group must encounter precisely the same
    work-group function.

Work-group Synchronization ::
    Constraints on the order of execution for work-items in a single
    work-group.

Work-pool ::
    A logical pool associated with a device that holds commands and
    work-groups from kernel-instances that are ready to execute.
    OpenCL does not constrain the order that commands and work-groups are
    scheduled for execution from the work-pool; i.e. a programmer must
    assume that they could be interleaved.
    There is one work-pool per device used by all command-queues associated
    with that device.
    The work-pool may be implemented in any manner as long as it assures
    that work-groups placed in the pool will eventually execute.

Work-item ::
    One of a collection of parallel executions of a _kernel_ invoked on a
    _device_ by a _command_.
    A _work-item_ is executed by one or more _processing elements_ as part
    of a _work-group_ executing on a _compute unit_.
    A _work-item_ is distinguished from other work-items by its _global ID_
    or the combination of its _work-group_ ID and its _local ID_ within a
    _work-group_.