Google Git
Sign in
chromium/external/github.com/KhronosGroup/OpenCL-Docs/refs/heads/master/./api/opencl_platform_layer.asciidoc
blob: 327a3aae299b90c5aa569977ca52e2c6a60cbb2a [file] [log] [blame] [edit]
// Copyright 2017-2020 The Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
[[opencl-platform-layer]]
= The OpenCL Platform Layer
This section describes the OpenCL platform layer which implements
platform-specific features that allow applications to query OpenCL devices,
device configuration information, and to create OpenCL contexts using one or
more devices.
== Querying Platform Info
[open,refpage='clGetPlatformIDs',desc='Query list of available platforms',type='protos']
--
The list of platforms available can be obtained with the function:
include::{generated}/api/protos/clGetPlatformIDs.txt[]
include::{generated}/api/version-notes/clGetPlatformIDs.asciidoc[]
* _num_entries_ is the number of {cl_platform_id_TYPE} entries that can be added to
_platforms_.
If _platforms_ is not `NULL`, the _num_entries_ must be greater than zero.
* _platforms_ returns a list of OpenCL platforms found.
The {cl_platform_id_TYPE} values returned in _platforms_ can be used to identify a
specific OpenCL platform.
If _platforms_ is `NULL`, this argument is ignored.
The number of OpenCL platforms returned is the minimum of the value
specified by _num_entries_ or the number of OpenCL platforms available.
* _num_platforms_ returns the number of OpenCL platforms available.
If _num_platforms_ is `NULL`, this argument is ignored.
// refError
{clGetPlatformIDs} returns {CL_SUCCESS} if the function is executed
successfully.
Otherwise, it returns one of the following errors:
* {CL_INVALID_VALUE} if _num_entries_ is equal to zero and _platforms_ is
not `NULL` or if both _num_platforms_ and _platforms_ are `NULL`.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--
[open,refpage='clGetPlatformInfo',desc='Query information about an OpenCL platform',type='protos']
--
Specific information about an OpenCL platform can be obtained with
the function:
include::{generated}/api/protos/clGetPlatformInfo.txt[]
include::{generated}/api/version-notes/clGetPlatformInfo.asciidoc[]
* _platform_ refers to the platform ID returned by {clGetPlatformIDs} or can
be `NULL`.
If _platform_ is `NULL`, the behavior is implementation-defined.
* _param_name_ is an enumeration constant that identifies the platform
information being queried.
It can be one of the following values as specified in the
<<platform-queries-table, Platform Queries>> table.
* _param_value_ is a pointer to memory location where appropriate values for a
given _param_name_, as specified in the <<platform-queries-table, Platform
Queries>> table, will be returned.
If _param_value_ is `NULL`, it is ignored.
* _param_value_size_ specifies the size in bytes of memory pointed to by
_param_value_.
This size in bytes must be {geq} size of return type specified in the
<<platform-queries-table, Platform Queries>> table.
* _param_value_size_ret_ returns the actual size in bytes of data being
queried by _param_name_.
If _param_value_size_ret_ is `NULL`, it is ignored.
The information that can be queried using {clGetPlatformInfo} is specified
in the <<platform-queries-table, Platform Queries>> table.
[[platform-queries-table]]
.List of supported param_names by <<clGetPlatformInfo>>
[width="100%",cols="<33%,<17%,<50%",options="header"]
|====
| Platform Info | Return Type | Description
| {CL_PLATFORM_PROFILE_anchor} footnote:[{fn-platform-profile}]
include::{generated}/api/version-notes/CL_PLATFORM_PROFILE.asciidoc[]
| {char_TYPE}[] footnote:[{fn-null-terminated-string}]
| OpenCL profile string.
Returns the profile name supported by the implementation.
The profile name returned can be one of the following strings:
FULL_PROFILE - if the implementation supports the OpenCL
specification (functionality defined as part of the core
specification and does not require any extensions to be supported).
EMBEDDED_PROFILE - if the implementation supports the OpenCL
embedded profile.
The embedded profile is defined to be a subset for each version of
OpenCL.
The embedded profile for OpenCL is described in
<<opencl-embedded-profile, OpenCL Embedded Profile>>.
| {CL_PLATFORM_VERSION_anchor}
include::{generated}/api/version-notes/CL_PLATFORM_VERSION.asciidoc[]
| {char_TYPE}[]
| OpenCL version string.
Returns the OpenCL version supported by the implementation.
This version string has the following format:
_OpenCL<space><major_version.minor_version><space><platform-specific
information>_
The _major_version.minor_version_ value returned will be one of 1.0,
1.1, 1.2, 2.0, 2.1, 2.2 or 3.0.
| {CL_PLATFORM_NUMERIC_VERSION_anchor}
include::{generated}/api/version-notes/CL_PLATFORM_NUMERIC_VERSION.asciidoc[]
| {cl_version_TYPE}
| Returns the detailed (major, minor, patch) version supported by the
platform. The major and minor version numbers returned must match
those returned via {CL_PLATFORM_VERSION}.
| {CL_PLATFORM_NAME_anchor}
include::{generated}/api/version-notes/CL_PLATFORM_NAME.asciidoc[]
| {char_TYPE}[]
| Platform name string.
| {CL_PLATFORM_VENDOR_anchor}
include::{generated}/api/version-notes/CL_PLATFORM_VENDOR.asciidoc[]
| {char_TYPE}[]
| Platform vendor string.
| {CL_PLATFORM_EXTENSIONS_anchor}
include::{generated}/api/version-notes/CL_PLATFORM_EXTENSIONS.asciidoc[]
| {char_TYPE}[]
| Returns a space separated list of extension names (the extension
names themselves do not contain any spaces) supported by the
platform.
Each extension that is supported by all devices associated with this
platform must be reported here.
| {CL_PLATFORM_EXTENSIONS_WITH_VERSION_anchor}
include::{generated}/api/version-notes/CL_PLATFORM_EXTENSIONS_WITH_VERSION.asciidoc[]
| {cl_name_version_TYPE}[]
| Returns an array of description (name and version) structures that lists
all the extensions supported by the platform. The same extension name
must not be reported more than once. The list of extensions reported
must match the list reported via {CL_PLATFORM_EXTENSIONS}.
| {CL_PLATFORM_HOST_TIMER_RESOLUTION_anchor}
include::{generated}/api/version-notes/CL_PLATFORM_HOST_TIMER_RESOLUTION.asciidoc[]
| {cl_ulong_TYPE}
| Returns the resolution of the host timer in nanoseconds as used by
{clGetDeviceAndHostTimer}.
Support for device and host timer synchronization is required for
platforms supporting OpenCL 2.1 or 2.2.
This value must be 0 for devices that do not support device and
host timer synchronization.
|====
// refError
{clGetPlatformInfo} returns {CL_SUCCESS} if the function is executed
successfully.
Otherwise, it returns one of the following
errors footnote:[{fn-error-precedence}].
* {CL_INVALID_PLATFORM} if _platform_ is not a valid platform.
* {CL_INVALID_VALUE} if _param_name_ is not one of the supported values or
if size in bytes specified by _param_value_size_ is < size of return
type as specified in the <<platform-queries-table,OpenCL Platform
Queries>> table, and _param_value_ is not a `NULL` value.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--
[[platform-querying-devices]]
== Querying Devices
[open,refpage='clGetDeviceIDs',desc='Query devices available on a platform',type='protos']
--
The list of devices available on a platform can be obtained using the
function footnote:[{fn-get-device-ids-all-or-subset}]:
include::{generated}/api/protos/clGetDeviceIDs.txt[]
include::{generated}/api/version-notes/clGetDeviceIDs.asciidoc[]
* _platform_ refers to the platform ID returned by {clGetPlatformIDs} or can
be `NULL`.
If _platform_ is `NULL`, the behavior is implementation-defined.
* _device_type_ is a bitfield that identifies the type of OpenCL device.
The _device_type_ can be used to query specific OpenCL devices or all OpenCL
devices available.
The valid values for _device_type_ are specified in the
<<device-types-table, Device Types>> table.
* _num_entries_ is the number of {cl_device_id_TYPE} entries that can be added to
_devices_.
If _devices_ is not `NULL`, the _num_entries_ must be greater than zero.
* _devices_ returns a list of OpenCL devices found.
The {cl_device_id_TYPE} values returned in _devices_ can be used to identify a
specific OpenCL device.
If _devices_ is `NULL`, this argument is ignored.
The number of OpenCL devices returned is the minimum of the value specified
by _num_entries_ or the number of OpenCL devices whose type matches
_device_type_.
* _num_devices_ returns the number of OpenCL devices available that match
_device_type_.
If _num_devices_ is `NULL`, this argument is ignored.
[[device-types-table]]
.List of supported device_types by <<clGetDeviceIDs>>
[width="100%",cols="<50%,<50%",options="header"]
|====
| Device Type | Description
| {CL_DEVICE_TYPE_CPU_anchor}
include::{generated}/api/version-notes/CL_DEVICE_TYPE_CPU.asciidoc[]
| An OpenCL device similar to a traditional CPU (Central Processing Unit).
The host processor that executes OpenCL host code may also be considered
a CPU OpenCL device.
| {CL_DEVICE_TYPE_GPU_anchor}
include::{generated}/api/version-notes/CL_DEVICE_TYPE_GPU.asciidoc[]
| An OpenCL device similar to a GPU (Graphics Processing Unit).
Many systems include a dedicated processor for graphics or rendering
that may be considered a GPU OpenCL device.
| {CL_DEVICE_TYPE_ACCELERATOR_anchor}
include::{generated}/api/version-notes/CL_DEVICE_TYPE_ACCELERATOR.asciidoc[]
| Dedicated devices that may accelerate OpenCL programs, such as FPGAs
(Field Programmable Gate Arrays), DSPs (Digital Signal Processors), or
AI (Artificial Intelligence) processors.
| {CL_DEVICE_TYPE_CUSTOM_anchor}
include::{generated}/api/version-notes/CL_DEVICE_TYPE_CUSTOM.asciidoc[]
| Specialized devices that implement some of the OpenCL runtime APIs but
do not support all required OpenCL functionality.
| {CL_DEVICE_TYPE_DEFAULT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_TYPE_DEFAULT.asciidoc[]
| The default OpenCL device in the platform.
The default OpenCL device must not be a {CL_DEVICE_TYPE_CUSTOM} device.
| {CL_DEVICE_TYPE_ALL_anchor}
include::{generated}/api/version-notes/CL_DEVICE_TYPE_ALL.asciidoc[]
| All OpenCL devices available in the platform, except for
{CL_DEVICE_TYPE_CUSTOM} devices.
|====
The device type is purely informational and has no semantic meaning.
Some devices may be more than one type.
For example, a {CL_DEVICE_TYPE_CPU} device may also be a
{CL_DEVICE_TYPE_GPU} device, or a {CL_DEVICE_TYPE_ACCELERATOR} device
may also be some other, more descriptive device type.
{CL_DEVICE_TYPE_CUSTOM} devices must not be combined with any other
device types.
One device in the platform should be a {CL_DEVICE_TYPE_DEFAULT} device.
The default device should also be a more specific device type, such
as {CL_DEVICE_TYPE_CPU} or {CL_DEVICE_TYPE_GPU}.
// refError
{clGetDeviceIDs} returns {CL_SUCCESS} if the function is executed
successfully.
Otherwise, it returns one of the following errors:
* {CL_INVALID_PLATFORM} if _platform_ is not a valid platform.
* {CL_INVALID_DEVICE_TYPE} if _device_type_ is not a valid value.
* {CL_INVALID_VALUE} if _num_entries_ is equal to zero and _devices_ is not
`NULL` or if both _num_devices_ and _devices_ are `NULL`.
* {CL_DEVICE_NOT_FOUND} if no OpenCL devices that matched _device_type_ were
found.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
The application can query specific capabilities of the OpenCL device(s)
returned by {clGetDeviceIDs}.
This can be used by the application to determine which device(s) to use.
--
[open,refpage='clGetDeviceInfo',desc='Query specific information about a device',type='protos']
--
To get specific information about an OpenCL device, call the function:
include::{generated}/api/protos/clGetDeviceInfo.txt[]
include::{generated}/api/version-notes/clGetDeviceInfo.asciidoc[]
* _device_ may be a device returned by {clGetDeviceIDs} or a sub-device
created by {clCreateSubDevices}.
If _device_ is a sub-device, the specific information for the sub-device
will be returned.
The information that can be queried using {clGetDeviceInfo} is specified in
the <<device-queries-table, Device Queries>> table.
* _param_name_ is an enumeration constant that identifies the device
information being queried.
It can be one of the following values as specified in the
<<device-queries-table, Device Queries>> table.
* _param_value_ is a pointer to memory location where appropriate values for a
given _param_name_, as specified in the <<device-queries-table, Device
Queries>> table, will be returned.
If _param_value_ is `NULL`, it is ignored.
* _param_value_size_ specifies the size in bytes of memory pointed to by
_param_value_.
This size in bytes must be {geq} size of return type specified in the
<<device-queries-table, Device Queries>> table.
* _param_value_size_ret_ returns the actual size in bytes of data being
queried by _param_name_.
If _param_value_size_ret_ is `NULL`, it is ignored.
The device queries described in the <<device-queries-table, Device Queries>>
table should return the same information for a root-level device i.e. a
device returned by {clGetDeviceIDs} and any sub-devices created from this
device except for the following queries:
* {CL_DEVICE_GLOBAL_MEM_CACHE_SIZE}
* {CL_DEVICE_BUILT_IN_KERNELS}
* {CL_DEVICE_PARENT_DEVICE}
* {CL_DEVICE_PARTITION_TYPE}
* {CL_DEVICE_REFERENCE_COUNT}
[[device-queries-table]]
.List of supported param_names by <<clGetDeviceInfo>>
[width="100%",cols="<33%,<17%,<50%",options="header"]
|====
| Device Info | Return Type | Description
| {CL_DEVICE_TYPE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_TYPE.asciidoc[]
| {cl_device_type_TYPE}
| The type or types of the OpenCL device.
Please see the <<device-types-table, Device Types>> table
for supported device types and device type combinations.
| {CL_DEVICE_VENDOR_ID_anchor} footnote:[{fn-vendor-id}]
include::{generated}/api/version-notes/CL_DEVICE_VENDOR_ID.asciidoc[]
| {cl_uint_TYPE}
| A unique device vendor identifier.
If the vendor has a PCI vendor ID, the low 16 bits must contain that PCI
vendor ID, and the remaining bits must be set to zero. Otherwise, the
value returned must be a valid Khronos vendor ID represented by type
{cl_khronos_vendor_id_TYPE}. Khronos vendor IDs are allocated starting at
0x10000, to distinguish them from the PCI vendor ID namespace.
| {CL_DEVICE_MAX_COMPUTE_UNITS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_COMPUTE_UNITS.asciidoc[]
| {cl_uint_TYPE}
| The number of parallel compute units on the OpenCL device.
A work-group executes on a single compute unit.
The minimum value is 1.
| {CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS.asciidoc[]
| {cl_uint_TYPE}
| Maximum dimensions that specify the global and local work-item IDs
used by the data parallel execution model. (Refer to
{clEnqueueNDRangeKernel}).
The minimum value is 3 for devices that are not of type
{CL_DEVICE_TYPE_CUSTOM}.
| {CL_DEVICE_MAX_WORK_ITEM_SIZES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_WORK_ITEM_SIZES.asciidoc[]
| {size_t_TYPE}[]
| Maximum number of work-items that can be specified in each dimension
of the work-group to {clEnqueueNDRangeKernel}.
Returns _n_ {size_t_TYPE} entries, where _n_ is the value returned by the
query for {CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS}.
The minimum value is (1, 1, 1) for devices that are not of type
{CL_DEVICE_TYPE_CUSTOM}.
| {CL_DEVICE_MAX_WORK_GROUP_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_WORK_GROUP_SIZE.asciidoc[]
| {size_t_TYPE}
| Maximum number of work-items in a work-group that a device is
capable of executing on a single compute unit, for any given
kernel-instance running on the device. (Refer also to
{clEnqueueNDRangeKernel} and {CL_KERNEL_WORK_GROUP_SIZE} ).
The minimum value is 1.
The returned value is an upper limit and will not necessarily
maximize performance.
This maximum may be larger than supported by a specific kernel
(refer to the {CL_KERNEL_WORK_GROUP_SIZE} query of {clGetKernelWorkGroupInfo}).
| {CL_DEVICE_PREFERRED_VECTOR_WIDTH_CHAR_anchor} +
{CL_DEVICE_PREFERRED_VECTOR_WIDTH_SHORT_anchor} +
{CL_DEVICE_PREFERRED_VECTOR_WIDTH_INT_anchor} +
{CL_DEVICE_PREFERRED_VECTOR_WIDTH_LONG_anchor} +
{CL_DEVICE_PREFERRED_VECTOR_WIDTH_FLOAT_anchor} +
{CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE_anchor} +
{CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF_anchor}
// Manually write this annotation as HALF is an odd-one-out in the table row
// (all other entries were added in OpenCL 1.0).
{CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF} is <<unified-spec, missing before>>
version 1.1.
| {cl_uint_TYPE}
| Preferred native vector width size for built-in scalar types that
can be put into vectors.
The vector width is defined as the number of scalar elements that
can be stored in the vector.
If double precision is not supported,
{CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE} must return 0.
If the *cl_khr_fp16* extension is not supported,
{CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF} must return 0.
| {CL_DEVICE_NATIVE_VECTOR_WIDTH_CHAR_anchor} +
{CL_DEVICE_NATIVE_VECTOR_WIDTH_SHORT_anchor} +
{CL_DEVICE_NATIVE_VECTOR_WIDTH_INT_anchor} +
{CL_DEVICE_NATIVE_VECTOR_WIDTH_LONG_anchor} +
{CL_DEVICE_NATIVE_VECTOR_WIDTH_FLOAT_anchor} +
{CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE_anchor} +
{CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF_anchor}
// The CHAR annotation here is used to convey the same information for all
// entries in this table row.
include::{generated}/api/version-notes/CL_DEVICE_NATIVE_VECTOR_WIDTH_CHAR.asciidoc[]
| {cl_uint_TYPE}
| Returns the native ISA vector width.
The vector width is defined as the number of scalar elements that
can be stored in the vector.
If double precision is not supported,
{CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE} must return 0.
If the *cl_khr_fp16* extension is not supported,
{CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF} must return 0.
| {CL_DEVICE_MAX_CLOCK_FREQUENCY_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_CLOCK_FREQUENCY.asciidoc[]
| {cl_uint_TYPE}
| Clock frequency of the device in MHz.
The meaning of this value is implementation-defined.
For devices with multiple clock domains, the clock frequency for any
of the clock domains may be returned.
For devices that dynamically change frequency for power or thermal
reasons, the returned clock frequency may be any valid frequency.
Note: This definition is <<unified-spec, missing before>> version 2.2.
Maximum configured clock frequency of the device in MHz.
Note: This definition is <<unified-spec, deprecated by>> version 2.2.
| {CL_DEVICE_ADDRESS_BITS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_ADDRESS_BITS.asciidoc[]
| {cl_uint_TYPE}
| The default compute device address space size of the global address
space specified as an unsigned integer value in bits.
Currently supported values are 32 or 64 bits.
| {CL_DEVICE_MAX_MEM_ALLOC_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_MEM_ALLOC_SIZE.asciidoc[]
| {cl_ulong_TYPE}
| Max size of memory object allocation in bytes.
The minimum value is max(min(1024 {times} 1024 {times} 1024, 1/4^th^
of {CL_DEVICE_GLOBAL_MEM_SIZE}), 32 {times} 1024 {times} 1024) for
devices that are not of type {CL_DEVICE_TYPE_CUSTOM}.
| {CL_DEVICE_IMAGE_SUPPORT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IMAGE_SUPPORT.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if images are supported by the OpenCL device and {CL_FALSE}
otherwise.
| {CL_DEVICE_MAX_READ_IMAGE_ARGS_anchor} footnote:[{fn-max-read-image-args}]
include::{generated}/api/version-notes/CL_DEVICE_MAX_READ_IMAGE_ARGS.asciidoc[]
| {cl_uint_TYPE}
| Max number of image objects arguments of a kernel declared with the
read_only qualifier.
The minimum value is 128 if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE}, the
value is 0 otherwise.
| {CL_DEVICE_MAX_WRITE_IMAGE_ARGS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_WRITE_IMAGE_ARGS.asciidoc[]
| {cl_uint_TYPE}
| Max number of image objects arguments of a kernel declared with the
write_only qualifier.
The minimum value is 64 if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE}, the
value is 0 otherwise.
| {CL_DEVICE_MAX_READ_WRITE_IMAGE_ARGS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_READ_WRITE_IMAGE_ARGS.asciidoc[]
| {cl_uint_TYPE}
| Max number of image objects arguments of a kernel declared with the
write_only or read_write qualifier.
Support for read-write image arguments is required for an OpenCL 2.0, 2.1,
or 2.2 device if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE}.
The minimum value is 64 if the device supports read-write images arguments,
and must be 0 for devices that do not support read-write images.
| {CL_DEVICE_IL_VERSION_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IL_VERSION.asciidoc[]
Also see extension *cl_khr_il_program*.
| {char_TYPE}[]
| The intermediate languages that can be supported by
{clCreateProgramWithIL} for this device.
Returns a space-separated list of IL version strings of the form
<IL_Prefix>_<Major_Version>.<Minor_Version>.
For an OpenCL 2.1 or 2.2 device, SPIR-V is a required IL prefix.
If the device does not support intermediate language programs, the
value must be `""` (an empty string).
| {CL_DEVICE_ILS_WITH_VERSION_anchor}
include::{generated}/api/version-notes/CL_DEVICE_ILS_WITH_VERSION.asciidoc[]
Also see extension *cl_khr_il_program*.
| {cl_name_version_TYPE}[]
| Returns an array of descriptions (name and version) for all supported
intermediate languages. Intermediate languages with the same name may be
reported more than once but each name and major/minor version
combination may only be reported once. The list of intermediate
languages reported must match the list reported via
{CL_DEVICE_IL_VERSION}.
For an OpenCL 2.1 or 2.2 device, at least one version of SPIR-V must
be reported.
| {CL_DEVICE_IMAGE2D_MAX_WIDTH_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IMAGE2D_MAX_WIDTH.asciidoc[]
| {size_t_TYPE}
| Max width of 2D image or 1D image not created from a buffer object
in pixels.
The minimum value is 16384 if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE},
the value is 0 otherwise.
| {CL_DEVICE_IMAGE2D_MAX_HEIGHT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IMAGE2D_MAX_HEIGHT.asciidoc[]
| {size_t_TYPE}
| Max height of 2D image in pixels.
The minimum value is 16384 if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE},
the value is 0 otherwise.
| {CL_DEVICE_IMAGE3D_MAX_WIDTH_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IMAGE3D_MAX_WIDTH.asciidoc[]
| {size_t_TYPE}
| Max width of 3D image in pixels.
The minimum value is 2048 if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE},
the value is 0 otherwise.
| {CL_DEVICE_IMAGE3D_MAX_HEIGHT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IMAGE3D_MAX_HEIGHT.asciidoc[]
| {size_t_TYPE}
| Max height of 3D image in pixels.
The minimum value is 2048 if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE},
the value is 0 otherwise.
| {CL_DEVICE_IMAGE3D_MAX_DEPTH_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IMAGE3D_MAX_DEPTH.asciidoc[]
| {size_t_TYPE}
| Max depth of 3D image in pixels.
The minimum value is 2048 if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE},
the value is 0 otherwise.
| {CL_DEVICE_IMAGE_MAX_BUFFER_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IMAGE_MAX_BUFFER_SIZE.asciidoc[]
| {size_t_TYPE}
| Max number of pixels for a 1D image created from a buffer object.
The minimum value is 65536 if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE},
the value is 0 otherwise.
| {CL_DEVICE_IMAGE_MAX_ARRAY_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IMAGE_MAX_ARRAY_SIZE.asciidoc[]
| {size_t_TYPE}
| Max number of images in a 1D or 2D image array.
The minimum value is 2048 if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE},
the value is 0 otherwise.
| {CL_DEVICE_MAX_SAMPLERS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_SAMPLERS.asciidoc[]
| {cl_uint_TYPE}
| Maximum number of samplers that can be used in a kernel.
The minimum value is 16 if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE},
the value is 0 otherwise.
| {CL_DEVICE_IMAGE_PITCH_ALIGNMENT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IMAGE_PITCH_ALIGNMENT.asciidoc[]
| {cl_uint_TYPE}
| The row pitch alignment size in pixels for 2D images created from a
buffer.
The value returned must be a power of 2.
Support for 2D images created from a buffer is required for an OpenCL 2.0, 2.1,
or 2.2 device if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE}.
This value must be 0 for devices that do not support 2D images created from a buffer.
| {CL_DEVICE_IMAGE_BASE_ADDRESS_ALIGNMENT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_IMAGE_BASE_ADDRESS_ALIGNMENT.asciidoc[]
| {cl_uint_TYPE}
| This query specifies the minimum alignment in pixels of the host_ptr
specified to {clCreateBuffer} or {clCreateBufferWithProperties} when a 2D image
is created from a buffer which was created using {CL_MEM_USE_HOST_PTR}.
The value returned must be a power of 2.
Support for 2D images created from a buffer is required for an OpenCL 2.0, 2.1,
or 2.2 device if {CL_DEVICE_IMAGE_SUPPORT} is {CL_TRUE}.
This value must be 0 for devices that do not support 2D images created from a buffer.
| {CL_DEVICE_MAX_PIPE_ARGS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_PIPE_ARGS.asciidoc[]
| {cl_uint_TYPE}
| The maximum number of pipe objects that can be passed as arguments
to a kernel.
The minimum value is 16 for devices supporting pipes, and must be
0 for devices that do not support pipes.
| {CL_DEVICE_PIPE_MAX_ACTIVE_RESERVATIONS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PIPE_MAX_ACTIVE_RESERVATIONS.asciidoc[]
| {cl_uint_TYPE}
| The maximum number of reservations that can be active for a pipe per
work-item in a kernel.
A work-group reservation is counted as one reservation per
work-item.
The minimum value is 1 for devices supporting pipes, and must be
0 for devices that do not support pipes.
| {CL_DEVICE_PIPE_MAX_PACKET_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PIPE_MAX_PACKET_SIZE.asciidoc[]
| {cl_uint_TYPE}
| The maximum size of pipe packet in bytes.
Support for pipes is required for an OpenCL 2.0, 2.1, or 2.2 device.
The minimum value is 1024 bytes if the device supports pipes, and must be
0 for devices that do not support pipes.
| {CL_DEVICE_MAX_PARAMETER_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_PARAMETER_SIZE.asciidoc[]
| {size_t_TYPE}
| Max size in bytes of all arguments that can be passed to a kernel.
The minimum value is 1024 for devices that are not of type
{CL_DEVICE_TYPE_CUSTOM}.
For this minimum value, only a maximum of 128 arguments can be
passed to a kernel
| {CL_DEVICE_MEM_BASE_ADDR_ALIGN_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MEM_BASE_ADDR_ALIGN.asciidoc[]
| {cl_uint_TYPE}
| Alignment requirement (in bits) for sub-buffer offsets.
The minimum value is the size (in bits) of the largest OpenCL
built-in data type supported by the device (long16 in FULL profile,
long16 or int16 in EMBEDDED profile) for devices that are not of
type {CL_DEVICE_TYPE_CUSTOM}.
| {CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE.asciidoc[]
| {cl_uint_TYPE}
| The minimum value is the size (in bytes) of the largest OpenCL data
type supported by the device (`long16` in FULL profile, `long16` or
`int16` in EMBEDDED profile).
| {CL_DEVICE_SINGLE_FP_CONFIG_anchor} footnote:native-rounding-modes[{fn-native-rounding-modes}]
include::{generated}/api/version-notes/CL_DEVICE_SINGLE_FP_CONFIG.asciidoc[]
| {cl_device_fp_config_TYPE}
| Describes single precision floating-point capability of the device.
This is a bit-field that describes one or more of the following
values:
{CL_FP_DENORM_anchor} - denorms are supported +
{CL_FP_INF_NAN_anchor} - INF and quiet NaNs are supported +
{CL_FP_ROUND_TO_NEAREST_anchor}-- round to nearest even rounding mode
supported +
{CL_FP_ROUND_TO_ZERO_anchor} - round to zero rounding mode supported +
{CL_FP_ROUND_TO_INF_anchor} - round to positive and negative infinity
rounding modes supported +
{CL_FP_FMA_anchor} - IEEE754-2008 fused multiply-add is supported +
{CL_FP_CORRECTLY_ROUNDED_DIVIDE_SQRT_anchor} - divide and sqrt are correctly
rounded as defined by the IEEE754 specification +
{CL_FP_SOFT_FLOAT_anchor} - Basic floating-point operations (such as
addition, subtraction, multiplication) are implemented in software
For the full profile, the mandated minimum floating-point capability
for devices that are not of type {CL_DEVICE_TYPE_CUSTOM} is:
{CL_FP_ROUND_TO_NEAREST} \| +
{CL_FP_INF_NAN}.
For the embedded profile, see the
<<embedded-profile-single-fp-config-requirements, dedicated table>>.
| {CL_DEVICE_DOUBLE_FP_CONFIG_anchor} footnote:native-rounding-modes[]
include::{generated}/api/version-notes/CL_DEVICE_DOUBLE_FP_CONFIG.asciidoc[]
Also see extension *cl_khr_fp64*.
| {cl_device_fp_config_TYPE}
| Describes double precision floating-point capability of the OpenCL
device.
This is a bit-field that describes one or more of the following
values:
{CL_FP_DENORM} - denorms are supported +
{CL_FP_INF_NAN} - INF and NaNs are supported +
{CL_FP_ROUND_TO_NEAREST} - round to nearest even rounding mode
supported +
{CL_FP_ROUND_TO_ZERO} - round to zero rounding mode supported +
{CL_FP_ROUND_TO_INF} - round to positive and negative infinity
rounding modes supported +
{CL_FP_FMA} - IEEE754-2008 fused multiply-add is supported +
{CL_FP_SOFT_FLOAT} - Basic floating-point operations (such as
addition, subtraction, multiplication) are implemented in software
Double precision is an optional feature so the mandated minimum
double precision floating-point capability is 0.
If double precision is supported by the device, then the minimum
double precision floating-point capability is:
{CL_FP_FMA} \| +
{CL_FP_ROUND_TO_NEAREST} \| +
{CL_FP_INF_NAN} \| +
{CL_FP_DENORM}.
| {CL_DEVICE_GLOBAL_MEM_CACHE_TYPE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_GLOBAL_MEM_CACHE_TYPE.asciidoc[]
| {cl_device_mem_cache_type_TYPE}
| Type of global memory cache supported.
Valid values are: {CL_NONE}, {CL_READ_ONLY_CACHE_anchor}, and
{CL_READ_WRITE_CACHE_anchor}.
| {CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE.asciidoc[]
| {cl_uint_TYPE}
| Size of global memory cache line in bytes.
| {CL_DEVICE_GLOBAL_MEM_CACHE_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_GLOBAL_MEM_CACHE_SIZE.asciidoc[]
| {cl_ulong_TYPE}
| Size of global memory cache in bytes.
| {CL_DEVICE_GLOBAL_MEM_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_GLOBAL_MEM_SIZE.asciidoc[]
| {cl_ulong_TYPE}
| Size of global device memory in bytes.
| {CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE.asciidoc[]
| {cl_ulong_TYPE}
| Max size in bytes of a constant buffer allocation.
The minimum value is 64 KB for devices that are not of type
{CL_DEVICE_TYPE_CUSTOM}.
| {CL_DEVICE_MAX_CONSTANT_ARGS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_CONSTANT_ARGS.asciidoc[]
| {cl_uint_TYPE}
| Max number of arguments declared with the `+__constant+` qualifier
in a kernel.
The minimum value is 8 for devices that are not of type
{CL_DEVICE_TYPE_CUSTOM}.
| {CL_DEVICE_MAX_GLOBAL_VARIABLE_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_GLOBAL_VARIABLE_SIZE.asciidoc[]
| {size_t_TYPE}
| The maximum number of bytes of storage that may be allocated for any
single variable in program scope or inside a function in an OpenCL
kernel language declared in the global address space.
Support for program scope global variables is required for an OpenCL 2.0,
2.1, or 2.2 device.
The minimum value is 64 KB if the device supports program scope global
variables, and must be 0 for devices that do not support program scope
global variables.
| {CL_DEVICE_GLOBAL_VARIABLE_PREFERRED_TOTAL_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_GLOBAL_VARIABLE_PREFERRED_TOTAL_SIZE.asciidoc[]
| {size_t_TYPE}
| Maximum preferred total size, in bytes, of all program variables in
the global address space.
This is a performance hint.
An implementation may place such variables in storage with optimized
device access.
This query returns the capacity of such storage.
The minimum value is 0.
| {CL_DEVICE_LOCAL_MEM_TYPE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_LOCAL_MEM_TYPE.asciidoc[]
| {cl_device_local_mem_type_TYPE}
| Type of local memory supported.
This can be set to {CL_LOCAL_anchor} implying dedicated local memory storage
such as SRAM , or {CL_GLOBAL_anchor}.
For custom devices, {CL_NONE} can also be returned indicating no local
memory support.
| {CL_DEVICE_LOCAL_MEM_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_LOCAL_MEM_SIZE.asciidoc[]
| {cl_ulong_TYPE}
| Size of local memory region in bytes.
The minimum value is 32 KB for devices that are not of type
{CL_DEVICE_TYPE_CUSTOM}.
| {CL_DEVICE_ERROR_CORRECTION_SUPPORT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_ERROR_CORRECTION_SUPPORT.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if the device implements error correction for all
accesses to compute device memory (global and constant).
Is {CL_FALSE} if the device does not implement such error correction.
| {CL_DEVICE_HOST_UNIFIED_MEMORY_anchor}
include::{generated}/api/version-notes/CL_DEVICE_HOST_UNIFIED_MEMORY.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if the device and the host have a unified memory subsystem
and is {CL_FALSE} otherwise.
| {CL_DEVICE_PROFILING_TIMER_RESOLUTION_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PROFILING_TIMER_RESOLUTION.asciidoc[]
| {size_t_TYPE}
| Describes the resolution of device timer.
This is measured in nanoseconds.
Refer to <<profiling-operations, Profiling Operations>> for details.
| {CL_DEVICE_ENDIAN_LITTLE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_ENDIAN_LITTLE.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if the OpenCL device is a little endian device and
{CL_FALSE} otherwise
| {CL_DEVICE_AVAILABLE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_AVAILABLE.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if the device is available and {CL_FALSE} otherwise.
A device is considered to be available if the device can be expected
to successfully execute commands enqueued to the device.
| {CL_DEVICE_COMPILER_AVAILABLE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_COMPILER_AVAILABLE.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_FALSE} if the implementation does not have a compiler available
to compile the program source.
Is {CL_TRUE} if the compiler is available.
This can be {CL_FALSE} for the embedded platform profile only.
| {CL_DEVICE_LINKER_AVAILABLE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_LINKER_AVAILABLE.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_FALSE} if the implementation does not have a linker available.
Is {CL_TRUE} if the linker is available.
This can be {CL_FALSE} for the embedded platform profile only.
This must be {CL_TRUE} if {CL_DEVICE_COMPILER_AVAILABLE} is {CL_TRUE}.
| {CL_DEVICE_EXECUTION_CAPABILITIES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_EXECUTION_CAPABILITIES.asciidoc[]
| {cl_device_exec_capabilities_TYPE}
| Describes the execution capabilities of the device.
This is a bit-field that describes one or more of the following
values:
{CL_EXEC_KERNEL_anchor} - The OpenCL device can execute OpenCL kernels. +
{CL_EXEC_NATIVE_KERNEL_anchor} - The OpenCL device can execute native
kernels.
The mandated minimum capability is: {CL_EXEC_KERNEL}.
| {CL_DEVICE_QUEUE_PROPERTIES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_QUEUE_PROPERTIES.asciidoc[]
| {cl_command_queue_properties_TYPE}
| See description of {CL_DEVICE_QUEUE_ON_HOST_PROPERTIES}.
| {CL_DEVICE_QUEUE_ON_HOST_PROPERTIES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_QUEUE_ON_HOST_PROPERTIES.asciidoc[]
| {cl_command_queue_properties_TYPE}
| Describes the on host command-queue properties supported by the
device.
This is a bit-field that describes one or more of the following
values:
{CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE} +
{CL_QUEUE_PROFILING_ENABLE}
These properties are described in the <<queue-properties-table,
Queue Properties>> table.
The mandated minimum capability is: {CL_QUEUE_PROFILING_ENABLE}.
| {CL_DEVICE_QUEUE_ON_DEVICE_PROPERTIES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_QUEUE_ON_DEVICE_PROPERTIES.asciidoc[]
| {cl_command_queue_properties_TYPE}
| Describes the on device command-queue properties supported by the
device.
This is a bit-field that describes one or more of the following
values:
{CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE} +
{CL_QUEUE_PROFILING_ENABLE}
These properties are described in the <<queue-properties-table,
Queue Properties>> table.
Support for on-device queues is required for an OpenCL 2.0, 2.1, or 2.2 device.
When on-device queues are supported, the mandated minimum capability is:
{CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE} \| +
{CL_QUEUE_PROFILING_ENABLE}.
Must be 0 for devices that do not support on-device queues.
| {CL_DEVICE_QUEUE_ON_DEVICE_PREFERRED_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_QUEUE_ON_DEVICE_PREFERRED_SIZE.asciidoc[]
| {cl_uint_TYPE}
| The preferred size of the device queue, in bytes.
Applications should use this size for the device queue to ensure
good performance.
The minimum value is 16 KB for devices supporting on-device queues,
and must be 0 for devices that do not support on-device queues.
| {CL_DEVICE_QUEUE_ON_DEVICE_MAX_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_QUEUE_ON_DEVICE_MAX_SIZE.asciidoc[]
| {cl_uint_TYPE}
| The maximum size of the device queue in bytes.
The minimum value is 256 KB for the full profile and 64 KB for the
embedded profile for devices supporting on-device queues,
and must be 0 for devices that do not support on-device queues.
| {CL_DEVICE_MAX_ON_DEVICE_QUEUES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_ON_DEVICE_QUEUES.asciidoc[]
| {cl_uint_TYPE}
| The maximum number of device queues that can be created for this
device in a single context.
The minimum value is 1 for devices supporting on-device queues,
and must be 0 for devices that do not support on-device queues.
| {CL_DEVICE_MAX_ON_DEVICE_EVENTS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_MAX_ON_DEVICE_EVENTS.asciidoc[]
| {cl_uint_TYPE}
| The maximum number of events in use by a device queue.
These refer to events returned by the `enqueue_` built-in functions
to a device queue or user events returned by the `create_user_event`
built-in function that have not been released.
The minimum value is 1024 for devices supporting on-device queues,
and must be 0 for devices that do not support on-device queues.
| {CL_DEVICE_BUILT_IN_KERNELS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_BUILT_IN_KERNELS.asciidoc[]
| {char_TYPE}[]
| A semi-colon separated list of built-in kernels supported by the
device.
An empty string is returned if no built-in kernels are supported by
the device.
| {CL_DEVICE_BUILT_IN_KERNELS_WITH_VERSION_anchor}
include::{generated}/api/version-notes/CL_DEVICE_BUILT_IN_KERNELS_WITH_VERSION.asciidoc[]
| {cl_name_version_TYPE}[]
| Returns an array of descriptions for the built-in kernels supported by
the device. Each built-in kernel may only be reported once. The list of
reported kernels must match the list returned via
{CL_DEVICE_BUILT_IN_KERNELS}.
| {CL_DEVICE_PLATFORM_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PLATFORM.asciidoc[]
| {cl_platform_id_TYPE}
| The platform associated with this device.
| {CL_DEVICE_NAME_anchor}
include::{generated}/api/version-notes/CL_DEVICE_NAME.asciidoc[]
| {char_TYPE}[]
| Device name string.
| {CL_DEVICE_VENDOR_anchor}
include::{generated}/api/version-notes/CL_DEVICE_VENDOR.asciidoc[]
| {char_TYPE}[]
| Vendor name string.
| {CL_DRIVER_VERSION_anchor}
include::{generated}/api/version-notes/CL_DRIVER_VERSION.asciidoc[]
| {char_TYPE}[]
| OpenCL software driver version string.
Follows a vendor-specific format.
| {CL_DEVICE_PROFILE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PROFILE.asciidoc[]
| {char_TYPE}[]
| OpenCL profile string.
Returns the profile name supported by the device.
The profile name returned can be one of the following strings:
FULL_PROFILE - if the device supports the OpenCL specification
(functionality defined as part of the core specification and does
not require any extensions to be supported).
EMBEDDED_PROFILE - if the device supports the OpenCL embedded
profile.
| {CL_DEVICE_VERSION_anchor}
include::{generated}/api/version-notes/CL_DEVICE_VERSION.asciidoc[]
| {char_TYPE}[]
| OpenCL version string.
Returns the OpenCL version supported by the device. This version
string has the following format:
_OpenCL<space><major_version.minor_version><space><vendor-specific
information>_
The major_version.minor_version value returned will be one of 1.0,
1.1, 1.2, 2.0, 2.1, 2.2, or 3.0.
| {CL_DEVICE_NUMERIC_VERSION_anchor}
include::{generated}/api/version-notes/CL_DEVICE_NUMERIC_VERSION.asciidoc[]
| {cl_version_TYPE}
| Returns the detailed (major, minor, patch) version supported by the
device. The major and minor version numbers returned must match
those returned via {CL_DEVICE_VERSION}.
| {CL_DEVICE_OPENCL_C_VERSION_anchor}
include::{generated}/api/version-notes/CL_DEVICE_OPENCL_C_VERSION.asciidoc[]
| {char_TYPE}[]
| Returns the highest fully backwards compatible OpenCL C version
supported by the compiler for the device.
For devices supporting compilation from OpenCL C source, this will
return a version string with the following format:
_OpenCL<space>C<space><major_version.minor_version><space><vendor-specific
information>_
For devices that support compilation from OpenCL C source:
Because OpenCL 3.0 is backwards compatible with OpenCL C 1.2,
an OpenCL 3.0 device must support at least OpenCL C 1.2.
An OpenCL 3.0 device may return an OpenCL C version newer
than OpenCL C 1.2 if and only if all optional OpenCL C
features are supported by the device for the newer version.
Support for OpenCL C 2.0 is required for an OpenCL 2.0, OpenCL 2.1,
or OpenCL 2.2 device.
Support for OpenCL C 1.2 is required for an OpenCL 1.2 device.
Support for OpenCL C 1.1 is required for an OpenCL 1.1 device.
Support for either OpenCL C 1.0 or OpenCL C 1.1 is required for
an OpenCL 1.0 device.
For devices that do not support compilation from OpenCL C source,
such as when {CL_DEVICE_COMPILER_AVAILABLE} is {CL_FALSE}, this
query may return an empty string.
This query has been superseded by the {CL_DEVICE_OPENCL_C_ALL_VERSIONS}
query, which returns a set of OpenCL C versions supported by a
device.
| {CL_DEVICE_OPENCL_C_ALL_VERSIONS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_OPENCL_C_ALL_VERSIONS.asciidoc[]
| {cl_name_version_TYPE}[]
| Returns an array of name, version descriptions listing all the versions
of OpenCL C supported by the compiler for the device.
In each returned description structure, the name field is required to be
"OpenCL C". The list may include both newer non-backwards compatible
OpenCL C versions, such as OpenCL C 3.0, and older OpenCL C versions
with mandatory backwards compatibility.
The version returned by {CL_DEVICE_OPENCL_C_VERSION} is required to be
present in the list.
For devices that support compilation from OpenCL C source:
Because OpenCL 3.0 is backwards compatible with OpenCL C 1.2,
and OpenCL C 1.2 is backwards compatible with OpenCL C 1.1 and
OpenCL C 1.0, support for at least OpenCL C 3.0, OpenCL C 1.2,
OpenCL C 1.1, and OpenCL C 1.0 is required for an OpenCL 3.0 device.
Support for OpenCL C 2.0, OpenCL C 1.2, OpenCL C 1.1, and OpenCL C
1.0 is required for an OpenCL 2.0, OpenCL 2.1, or OpenCL 2.2 device.
Support for OpenCL C 1.2, OpenCL C 1.1, and OpenCL C 1.0 is required
for an OpenCL 1.2 device.
Support for OpenCL C 1.1 and OpenCL C 1.0 is required for an
OpenCL 1.1 device.
Support for at least OpenCL C 1.0 is required for an OpenCL 1.0 device.
For devices that do not support compilation from OpenCL C source,
this query may return an empty array.
| {CL_DEVICE_OPENCL_C_FEATURES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_OPENCL_C_FEATURES.asciidoc[]
| {cl_name_version_TYPE}[]
| Returns an array of optional OpenCL C features supported by the
compiler for the device alongside the OpenCL C version that introduced
the feature macro.
For example, if a compiler supports an OpenCL C 3.0 feature, the
returned name will be the full name of the OpenCL C feature macro, and
the returned version will be 3.0.0.
For devices that do not support compilation from OpenCL C source,
this query may return an empty array.
| {CL_DEVICE_EXTENSIONS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_EXTENSIONS.asciidoc[]
| {char_TYPE}[]
| Returns a space separated list of extension names (the extension
names themselves do not contain any spaces) supported by the device.
The list of extension names may include Khronos approved extension
names and vendor specified extension names.
The following Khronos extension names must be returned by
all devices that support OpenCL 1.1:
*cl_khr_byte_addressable_store* +
*cl_khr_global_int32_base_atomics* +
*cl_khr_global_int32_extended_atomics* +
*cl_khr_local_int32_base_atomics* +
*cl_khr_local_int32_extended_atomics*
Additionally, the following Khronos extension names must be returned
by all devices that support OpenCL 1.2 when and only when the optional
feature is supported:
*cl_khr_fp64*
Additionally, the following Khronos extension names must be returned
by all devices that support OpenCL 2.0, OpenCL 2.1, or OpenCL 2.2.
For devices that support OpenCL 3.0, these extension names must
be returned when and only when the optional feature is supported:
*cl_khr_3d_image_writes* +
*cl_khr_depth_images* +
*cl_khr_image2d_from_buffer*
Please refer to the OpenCL Extension Specification or vendor
provided documentation for a detailed description of these extensions.
| {CL_DEVICE_EXTENSIONS_WITH_VERSION_anchor}
include::{generated}/api/version-notes/CL_DEVICE_EXTENSIONS_WITH_VERSION.asciidoc[]
| {cl_name_version_TYPE}[]
| Returns an array of description (name and version) structures. The same
extension name must not be reported more than once. The list of
extensions reported must match the list reported via
{CL_DEVICE_EXTENSIONS}.
See {CL_DEVICE_EXTENSIONS_anchor} for a list of extensions that are
required to be reported for a given OpenCL version.
| {CL_DEVICE_PRINTF_BUFFER_SIZE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PRINTF_BUFFER_SIZE.asciidoc[]
| {size_t_TYPE}
| Maximum size in bytes of the internal buffer that holds the output
of printf calls from a kernel.
The minimum value for the FULL profile is 1 MB.
| {CL_DEVICE_PREFERRED_INTEROP_USER_SYNC_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PREFERRED_INTEROP_USER_SYNC.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if the devices preference is for the user to be
responsible for synchronization, when sharing memory objects between
OpenCL and other APIs such as DirectX, {CL_FALSE} if the device /
implementation has a performant path for performing synchronization
of memory object shared between OpenCL and other APIs such as
DirectX.
| {CL_DEVICE_PARENT_DEVICE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PARENT_DEVICE.asciidoc[]
| {cl_device_id_TYPE}
| Returns the {cl_device_id_TYPE} of the parent device to which this
sub-device belongs.
If _device_ is a root-level device, a `NULL` value is returned.
| {CL_DEVICE_PARTITION_MAX_SUB_DEVICES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PARTITION_MAX_SUB_DEVICES.asciidoc[]
| {cl_uint_TYPE}
| Returns the maximum number of sub-devices that can be created when a
device is partitioned.
The value returned cannot exceed {CL_DEVICE_MAX_COMPUTE_UNITS}.
| {CL_DEVICE_PARTITION_PROPERTIES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PARTITION_PROPERTIES.asciidoc[]
| {cl_device_partition_property_TYPE}[]
| Returns the list of partition types supported by _device_.
This is an array of {cl_device_partition_property_TYPE} values drawn from
the following list:
{CL_DEVICE_PARTITION_EQUALLY} +
{CL_DEVICE_PARTITION_BY_COUNTS} +
{CL_DEVICE_PARTITION_BY_AFFINITY_DOMAIN}
If the device cannot be partitioned (i.e. there is no partitioning
scheme supported by the device that will return at least two
subdevices), a value of 0 will be returned.
| {CL_DEVICE_PARTITION_AFFINITY_DOMAIN_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PARTITION_AFFINITY_DOMAIN.asciidoc[]
| {cl_device_affinity_domain_TYPE}
| Returns the list of supported affinity domains for partitioning the
device using {CL_DEVICE_PARTITION_BY_AFFINITY_DOMAIN}.
This is a bit-field that describes one or more of the following
values:
{CL_DEVICE_AFFINITY_DOMAIN_NUMA_anchor} +
{CL_DEVICE_AFFINITY_DOMAIN_L4_CACHE_anchor} +
{CL_DEVICE_AFFINITY_DOMAIN_L3_CACHE_anchor} +
{CL_DEVICE_AFFINITY_DOMAIN_L2_CACHE_anchor} +
{CL_DEVICE_AFFINITY_DOMAIN_L1_CACHE_anchor} +
{CL_DEVICE_AFFINITY_DOMAIN_NEXT_PARTITIONABLE_anchor}
If the device does not support any affinity domains, a value of 0
will be returned.
| {CL_DEVICE_PARTITION_TYPE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PARTITION_TYPE.asciidoc[]
| {cl_device_partition_property_TYPE}[]
| Returns the properties argument specified in {clCreateSubDevices} if
device is a sub-device.
In the case where the properties argument to {clCreateSubDevices} is
{CL_DEVICE_PARTITION_BY_AFFINITY_DOMAIN},
{CL_DEVICE_AFFINITY_DOMAIN_NEXT_PARTITIONABLE}, the affinity domain
used to perform the partition will be returned.
This can be one of the following values:
{CL_DEVICE_AFFINITY_DOMAIN_NUMA} +
{CL_DEVICE_AFFINITY_DOMAIN_L4_CACHE} +
{CL_DEVICE_AFFINITY_DOMAIN_L3_CACHE} +
{CL_DEVICE_AFFINITY_DOMAIN_L2_CACHE} +
{CL_DEVICE_AFFINITY_DOMAIN_L1_CACHE}
Otherwise the implementation may either return a
_param_value_size_ret_ of 0 i.e. there is no partition type
associated with device or can return a property value of 0 (where 0
is used to terminate the partition property list) in the memory that
_param_value_ points to.
| {CL_DEVICE_REFERENCE_COUNT_anchor} footnote:[{fn-reference-count-usage}]
include::{generated}/api/version-notes/CL_DEVICE_REFERENCE_COUNT.asciidoc[]
| {cl_uint_TYPE}
| Returns the _device_ reference count.
If the device is a root-level device, a reference count of one is
returned.
| {CL_DEVICE_SVM_CAPABILITIES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_SVM_CAPABILITIES.asciidoc[]
| {cl_device_svm_capabilities_TYPE}
| Describes the various shared virtual memory (SVM) memory
allocation types the device supports.
This is a bit-field that describes a combination of the following
values:
{CL_DEVICE_SVM_COARSE_GRAIN_BUFFER_anchor} - Support for coarse-grain buffer
sharing using {clSVMAlloc}.
Memory consistency is guaranteed at synchronization points and the
host must use calls to {clEnqueueMapBuffer} and
{clEnqueueUnmapMemObject}. +
{CL_DEVICE_SVM_FINE_GRAIN_BUFFER_anchor} - Support for fine-grain buffer
sharing using {clSVMAlloc}.
Memory consistency is guaranteed at synchronization points without
need for {clEnqueueMapBuffer} and {clEnqueueUnmapMemObject}. +
{CL_DEVICE_SVM_FINE_GRAIN_SYSTEM_anchor} - Support for sharing the host's
entire virtual memory including memory allocated using *malloc*.
Memory consistency is guaranteed at synchronization points. +
{CL_DEVICE_SVM_ATOMICS_anchor} - Support for the OpenCL 2.0 atomic
operations that provide memory consistency across the host and all
OpenCL devices supporting fine-grain SVM allocations.
The mandated minimum capability for an OpenCL 2.0, 2.1, or 2.2 device is
{CL_DEVICE_SVM_COARSE_GRAIN_BUFFER}.
For other device versions there is no mandated minimum capability.
| {CL_DEVICE_PREFERRED_PLATFORM_ATOMIC_ALIGNMENT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PREFERRED_PLATFORM_ATOMIC_ALIGNMENT.asciidoc[]
| {cl_uint_TYPE}
| Returns the value representing the preferred alignment in bytes for
OpenCL 2.0 fine-grained SVM atomic types.
This query can return 0 which indicates that the preferred alignment
is aligned to the natural size of the type.
| {CL_DEVICE_PREFERRED_GLOBAL_ATOMIC_ALIGNMENT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PREFERRED_GLOBAL_ATOMIC_ALIGNMENT.asciidoc[]
| {cl_uint_TYPE}
| Returns the value representing the preferred alignment in bytes for
OpenCL 2.0 atomic types to global memory.
This query can return 0 which indicates that the preferred alignment
is aligned to the natural size of the type.
| {CL_DEVICE_PREFERRED_LOCAL_ATOMIC_ALIGNMENT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PREFERRED_LOCAL_ATOMIC_ALIGNMENT.asciidoc[]
| {cl_uint_TYPE}
| Returns the value representing the preferred alignment in bytes for
OpenCL 2.0 atomic types to local memory.
This query can return 0 which indicates that the preferred alignment
is aligned to the natural size of the type.
| {CL_DEVICE_MAX_NUM_SUB_GROUPS_anchor}
// Note: This sub-group property is not in cl_khr_subgroups.
include::{generated}/api/version-notes/CL_DEVICE_MAX_NUM_SUB_GROUPS.asciidoc[]
| {cl_uint_TYPE}
| Maximum number of sub-groups in a work-group that a device is
capable of executing on a single compute unit, for any given
kernel-instance running on the device.
The minimum value is 1 if the device supports subgroups, and must be
0 for devices that do not support subgroups.
Support for subgroups is required for an OpenCL 2.1 or 2.2 device.
(Refer also to {clGetKernelSubGroupInfo}.)
| {CL_DEVICE_SUB_GROUP_INDEPENDENT_FORWARD_PROGRESS_anchor}
// Note: This sub-group property is not in cl_khr_subgroups.
include::{generated}/api/version-notes/CL_DEVICE_SUB_GROUP_INDEPENDENT_FORWARD_PROGRESS.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if this device supports independent forward progress of
sub-groups, {CL_FALSE} otherwise.
This query must return {CL_TRUE} for devices that support the
*cl_khr_subgroups* extension, and must return {CL_FALSE} for
devices that do not support subgroups.
| {CL_DEVICE_ATOMIC_MEMORY_CAPABILITIES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_ATOMIC_MEMORY_CAPABILITIES.asciidoc[]
| {cl_device_atomic_capabilities_TYPE}
| Describes the various memory orders and scopes that the device supports for atomic memory operations.
This is a bit-field that describes a combination of the following
values:
{CL_DEVICE_ATOMIC_ORDER_RELAXED_anchor} - Support for the *relaxed* memory order. +
{CL_DEVICE_ATOMIC_ORDER_ACQ_REL_anchor} - Support for the *acquire*, *release*, and *acquire-release* memory orders. +
{CL_DEVICE_ATOMIC_ORDER_SEQ_CST_anchor} - Support for the *sequentially consistent* memory order.
Because atomic memory orders are hierarchical, a device that supports a strong memory order must also support all weaker memory orders.
{CL_DEVICE_ATOMIC_SCOPE_WORK_ITEM_anchor} footnote:[{fn-atomic-scope-work-item}] - Support for memory ordering constraints that apply to a single work-item. +
{CL_DEVICE_ATOMIC_SCOPE_WORK_GROUP_anchor} - Support for memory ordering constraints that apply to all work-items in a work-group. +
{CL_DEVICE_ATOMIC_SCOPE_DEVICE_anchor} - Support for memory ordering constraints that apply to all work-items executing on the device. +
{CL_DEVICE_ATOMIC_SCOPE_ALL_DEVICES_anchor} - Support for memory ordering constraints that apply to all work-items executing across all devices that can share SVM memory with each other and the host process.
Because atomic scopes are hierarchical, a device that supports a wide scope must also support all narrower scopes, except for the work-item scope, which is a special case.
The mandated minimum capability is:
{CL_DEVICE_ATOMIC_ORDER_RELAXED} \| +
{CL_DEVICE_ATOMIC_SCOPE_WORK_GROUP}
| {CL_DEVICE_ATOMIC_FENCE_CAPABILITIES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_ATOMIC_FENCE_CAPABILITIES.asciidoc[]
| {cl_device_atomic_capabilities_TYPE}
| Describes the various memory orders and scopes that the device supports for atomic fence operations.
This is a bit-field that has the same set of possible values as described for {CL_DEVICE_ATOMIC_MEMORY_CAPABILITIES}.
The mandated minimum capability is:
{CL_DEVICE_ATOMIC_ORDER_RELAXED} \| +
{CL_DEVICE_ATOMIC_ORDER_ACQ_REL} \| +
{CL_DEVICE_ATOMIC_SCOPE_WORK_GROUP}
| {CL_DEVICE_NON_UNIFORM_WORK_GROUP_SUPPORT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_NON_UNIFORM_WORK_GROUP_SUPPORT.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if the device supports non-uniform work-groups, and {CL_FALSE} otherwise.
// This query didn't exist pre-OpenCL 3.0, but:
//Support for non-uniform work-groups is required for an OpenCL 2.0, 2.1, or 2.2 device.
| {CL_DEVICE_WORK_GROUP_COLLECTIVE_FUNCTIONS_SUPPORT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_WORK_GROUP_COLLECTIVE_FUNCTIONS_SUPPORT.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if the device supports work-group collective functions e.g. `work_group_broadcast`, `work_group_reduce`, and `work_group_scan`, and {CL_FALSE} otherwise.
// This query didn't exist pre-OpenCL 3.0, but:
//Support for work-group collective functions is required for an OpenCL 2.0, 2.1, or 2.2 device.
| {CL_DEVICE_GENERIC_ADDRESS_SPACE_SUPPORT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_GENERIC_ADDRESS_SPACE_SUPPORT.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if the device supports the generic address space and its associated built-in functions, and {CL_FALSE} otherwise.
// This query didn't exist pre-OpenCL 3.0, but:
//Support for the generic address space is required for an OpenCL 2.0, 2.1, or 2.2 device.
| {CL_DEVICE_DEVICE_ENQUEUE_CAPABILITIES_anchor}
include::{generated}/api/version-notes/CL_DEVICE_DEVICE_ENQUEUE_CAPABILITIES.asciidoc[]
| {cl_device_device_enqueue_capabilities_TYPE}
| Describes device-side enqueue capabilities of the device.
This is a bit-field that describes one or more of the following
values:
{CL_DEVICE_QUEUE_SUPPORTED_anchor} - Device supports device-side enqueue and on-device queues. +
{CL_DEVICE_QUEUE_REPLACEABLE_DEFAULT_anchor} - Device supports a replaceable default on-device queue.
If {CL_DEVICE_QUEUE_REPLACEABLE_DEFAULT} is set, {CL_DEVICE_QUEUE_SUPPORTED} must also be set.
Devices that set {CL_DEVICE_QUEUE_SUPPORTED} for {CL_DEVICE_DEVICE_ENQUEUE_CAPABILITIES} must also return {CL_TRUE} for {CL_DEVICE_GENERIC_ADDRESS_SPACE_SUPPORT}.
// This query didn't exist pre-OpenCL 3.0, but:
//Support for device-side enqueue and on-device queues is required for an OpenCL 2.0, 2.1, or 2.2 device.
| {CL_DEVICE_PIPE_SUPPORT_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PIPE_SUPPORT.asciidoc[]
| {cl_bool_TYPE}
| Is {CL_TRUE} if the device supports pipes, and {CL_FALSE} otherwise.
Devices that return {CL_TRUE} for {CL_DEVICE_PIPE_SUPPORT} must also return {CL_TRUE} for {CL_DEVICE_GENERIC_ADDRESS_SPACE_SUPPORT}.
// This query didn't exist pre-OpenCL 3.0, but:
//Support for pipes is required for an OpenCL 2.0, 2.1, or 2.2 device.
| {CL_DEVICE_PREFERRED_WORK_GROUP_SIZE_MULTIPLE_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PREFERRED_WORK_GROUP_SIZE_MULTIPLE.asciidoc[]
| {size_t_TYPE}
| Returns the preferred multiple of work-group size for the given device.
This is a performance hint intended as a guide when specifying the local work size argument to {clEnqueueNDRangeKernel}.
(Refer also to {clGetKernelWorkGroupInfo} where {CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE}
can return a different value to {CL_DEVICE_PREFERRED_WORK_GROUP_SIZE_MULTIPLE} which may be more optimal.)
| {CL_DEVICE_LATEST_CONFORMANCE_VERSION_PASSED_anchor}
include::{generated}/api/version-notes/CL_DEVICE_LATEST_CONFORMANCE_VERSION_PASSED.asciidoc[]
| {char_TYPE}[]
| Returns the latest version of the conformance test suite that this device
has fully passed in accordance with the official conformance process.
|====
// refError
{clGetDeviceInfo} returns {CL_SUCCESS} if the function is executed
successfully.
Otherwise, it returns one of the following errors:
* {CL_INVALID_DEVICE} if _device_ is not a valid device.
* {CL_INVALID_VALUE} if _param_name_ is not one of the supported values or
if size in bytes specified by _param_value_size_ is < size of return
type as specified in the <<device-queries-table, Device Queries>> table
and _param_value_ is not a `NULL` value or if _param_name_ is a value
that is available as an extension and the corresponding extension is not
supported by the device.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--
[open,refpage='clGetDeviceAndHostTimer',desc='Query synchronized host and device timestamps',type='protos']
--
To query device and host timestamps, call the function:
include::{generated}/api/protos/clGetDeviceAndHostTimer.txt[]
include::{generated}/api/version-notes/clGetDeviceAndHostTimer.asciidoc[]
* _device_ is a device returned by {clGetDeviceIDs}.
* _device_timestamp_ will be updated with the value of the device timer in
nanoseconds.
The resolution of the timer is the same as the device profiling timer
returned by {clGetDeviceInfo} and the {CL_DEVICE_PROFILING_TIMER_RESOLUTION}
query.
* _host_timestamp_ will be updated with the value of the host timer in
nanoseconds at the closest possible point in time to that at which
_device_timer_ was returned.
The resolution of the timer may be queried via {clGetPlatformInfo} and the
flag {CL_PLATFORM_HOST_TIMER_RESOLUTION}.
{clGetDeviceAndHostTimer} returns a reasonably synchronized pair of
timestamps from the device timer and the host timer as seen by _device_.
Implementations may need to execute this query with a high latency in order
to provide reasonable synchronization of the timestamps.
The host timestamp and device timestamp returned by this function and
{clGetHostTimer} each have an implementation defined timebase.
The timestamps will always be in their respective timebases regardless of
which query function is used.
The timestamp returned from {clGetEventProfilingInfo} for an event on a
device and a device timestamp queried from the same device will always be in
the same timebase.
// refError
{clGetDeviceAndHostTimer} will return {CL_SUCCESS} with a time value in
_host_timestamp_ if provided.
Otherwise, it returns one of the following errors:
* {CL_INVALID_DEVICE} if _device_ is not a valid device.
* {CL_INVALID_OPERATION} if the platform associated with _device_ does not
support device and host timer synchronization.
* {CL_INVALID_VALUE} if _host_timestamp_ or _device_timestamp_ is `NULL`.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--
[open,refpage='clGetHostTimer',desc='Query the host clock',type='protos']
--
To query the host clock, call the function:
include::{generated}/api/protos/clGetHostTimer.txt[]
include::{generated}/api/version-notes/clGetHostTimer.asciidoc[]
* _device_ is a device returned by {clGetDeviceIDs}.
* _host_timestamp_ will be updated with the value of the current timer in
nanoseconds.
The resolution of the timer may be queried via {clGetPlatformInfo} and the
flag {CL_PLATFORM_HOST_TIMER_RESOLUTION}.
{clGetHostTimer} returns the current value of the host clock as seen by
_device_.
This value is in the same timebase as the _host_timestamp_ returned from
{clGetDeviceAndHostTimer}.
The implementation will return with as low a latency as possible to allow a
correlation with a subsequent application sampled time.
The host timestamp and device timestamp returned by this function and
{clGetDeviceAndHostTimer} each have an implementation defined timebase.
The timestamps will always be in their respective timebases regardless of
which query function is used.
The timestamp returned from {clGetEventProfilingInfo} for an event on a
device and a device timestamp queried from the same device will always be in
the same timebase.
{clGetHostTimer} will return {CL_SUCCESS} with a time value in
_host_timestamp_ if provided.
Otherwise, it returns one of the following errors:
* {CL_INVALID_DEVICE} if _device_ is not a valid device.
* {CL_INVALID_OPERATION} if the platform associated with _device_ does not
support device and host timer synchronization.
* {CL_INVALID_VALUE} if _host_timestamp_ is `NULL`.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--
== Partitioning a Device
NOTE: Partitioning devices is <<unified-spec, missing before>> version 1.2.
[open,refpage='clCreateSubDevices',desc='Create sub-devices partitioning an OpenCL device',type='protos']
--
To create sub-devices partitioning an OpenCL device, call the function:
include::{generated}/api/protos/clCreateSubDevices.txt[]
include::{generated}/api/version-notes/clCreateSubDevices.asciidoc[]
* _in_device_ is the device to be partitioned.
* _properties_ specifies how _in_device_ is to be partitioned, described by a
partition name and its corresponding value.
Each partition name is immediately followed by the corresponding desired
value.
The list is terminated with 0.
The list of supported partitioning schemes is described in the
<<subdevice-partition-table, Subdevice Partition>> table.
Only one of the listed partitioning schemes can be specified in
_properties_.
* _num_devices_ is the size of memory pointed to by _out_devices_ specified as
the number of {cl_device_id_TYPE} entries.
* _out_devices_ is the buffer where the OpenCL sub-devices will be returned.
If _out_devices_ is `NULL`, this argument is ignored.
If _out_devices_ is not `NULL`, _num_devices_ must be greater than or equal
to the number of sub-devices that _device_ may be partitioned into according
to the partitioning scheme specified in _properties_.
* _num_devices_ret_ returns the number of sub-devices that _device_ may be
partitioned into according to the partitioning scheme specified in
_properties_.
If _num_devices_ret_ is `NULL`, it is ignored.
{clCreateSubDevices} creates an array of sub-devices that each reference a
non-intersecting set of compute units within _in_device_, according to the
partition scheme given by _properties_.
The output sub-devices may be used in every way that the root (or parent)
device can be used, including creating contexts, building programs, further
calls to {clCreateSubDevices} and creating command-queues.
When a command-queue is created against a sub-device, the commands enqueued
on the queue are executed only on the sub-device.
[[subdevice-partition-table]]
.List of supported partition schemes by <<clCreateSubDevices>>
[width="100%",cols="<33%,<17%,<50%",options="header"]
|====
| Partition Property | Partition Value | Description
| {CL_DEVICE_PARTITION_EQUALLY_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PARTITION_EQUALLY.asciidoc[]
| {cl_uint_TYPE}
| Split the aggregate device into as many smaller aggregate devices as
can be created, each containing _n_ compute units.
The value _n_ is passed as the value accompanying this property.
If _n_ does not divide evenly into
{CL_DEVICE_MAX_COMPUTE_UNITS}, then the remaining compute
units are not used.
| {CL_DEVICE_PARTITION_BY_COUNTS_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PARTITION_BY_COUNTS.asciidoc[]
| {cl_uint_TYPE}
| This property is followed by a list of compute unit counts
terminated with 0 or {CL_DEVICE_PARTITION_BY_COUNTS_LIST_END_anchor}.
For each non-zero count _m_ in the list, a sub-device is created
with _m_ compute units in it.
The number of non-zero count entries in the list may not exceed
{CL_DEVICE_PARTITION_MAX_SUB_DEVICES}.
The total number of compute units specified may not exceed
{CL_DEVICE_MAX_COMPUTE_UNITS}.
| {CL_DEVICE_PARTITION_BY_AFFINITY_DOMAIN_anchor}
include::{generated}/api/version-notes/CL_DEVICE_PARTITION_BY_AFFINITY_DOMAIN.asciidoc[]
| {cl_device_affinity_domain_TYPE}
| Split the device into smaller aggregate devices containing one or
more compute units that all share part of a cache hierarchy.
The value accompanying this property may be drawn from the following
list:
{CL_DEVICE_AFFINITY_DOMAIN_NUMA} - Split the device into sub-devices
comprised of compute units that share a NUMA node.
{CL_DEVICE_AFFINITY_DOMAIN_L4_CACHE} - Split the device into
sub-devices comprised of compute units that share a level 4 data
cache.
{CL_DEVICE_AFFINITY_DOMAIN_L3_CACHE} - Split the device into
sub-devices comprised of compute units that share a level 3 data
cache.
{CL_DEVICE_AFFINITY_DOMAIN_L2_CACHE} - Split the device into
sub-devices comprised of compute units that share a level 2 data
cache.
{CL_DEVICE_AFFINITY_DOMAIN_L1_CACHE} - Split the device into
sub-devices comprised of compute units that share a level 1 data
cache.
{CL_DEVICE_AFFINITY_DOMAIN_NEXT_PARTITIONABLE} - Split the device
along the next partitionable affinity domain.
The implementation shall find the first level along which the device
or sub-device may be further subdivided in the order NUMA, L4, L3,
L2, L1, and partition the device into sub-devices comprised of
compute units that share memory subsystems at this level.
The user may determine what happened by calling
{clGetDeviceInfo}({CL_DEVICE_PARTITION_TYPE}) on the sub-devices.
|====
// refError
{clCreateSubDevices} returns {CL_SUCCESS} if the partition is created
successfully.
Otherwise, it returns a `NULL` value with the following error values
returned in _errcode_ret_:
* {CL_INVALID_DEVICE} if _in_device_ is not a valid device.
* {CL_INVALID_VALUE} if values specified in _properties_ are not valid or if
values specified in _properties_ are valid but not supported by the
device.
* {CL_INVALID_VALUE} if _out_devices_ is not `NULL` and _num_devices_ is
less than the number of sub-devices created by the partition scheme.
* {CL_DEVICE_PARTITION_FAILED} if the partition name is supported by the
implementation but in_device could not be further partitioned.
* {CL_INVALID_DEVICE_PARTITION_COUNT} if the partition name specified in
_properties_ is {CL_DEVICE_PARTITION_BY_COUNTS} and the number of
sub-devices requested exceeds {CL_DEVICE_PARTITION_MAX_SUB_DEVICES} or the
total number of compute units requested exceeds
{CL_DEVICE_MAX_COMPUTE_UNITS} for _in_device_, or the number of
compute units requested for one or more sub-devices is less than zero or
the number of sub-devices requested exceeds
{CL_DEVICE_MAX_COMPUTE_UNITS} for _in_device_.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
A few examples that describe how to specify partition properties in
_properties_ argument to {clCreateSubDevices} are given below:
To partition a device containing 16 compute units into two sub-devices, each
containing 8 compute units, pass the following in _properties_:
[source,c]
----
{ CL_DEVICE_PARTITION_EQUALLY, 8,
0 } // 0 terminates the property list
----
To partition a device with four compute units into two sub-devices with one
sub-device containing 3 compute units and the other sub-device 1 compute
unit, pass the following in properties argument:
[source,c]
----
{ CL_DEVICE_PARTITION_BY_COUNTS,
3, 1, CL_DEVICE_PARTITION_BY_COUNTS_LIST_END,
0 } // 0 terminates the property list
----
To split a device along the outermost cache line (if any), pass the
following in properties argument:
[source,c]
----
{ CL_DEVICE_PARTITION_BY_AFFINITY_DOMAIN,
CL_DEVICE_AFFINITY_DOMAIN_NEXT_PARTITIONABLE,
0 } // 0 terminates the property list
----
--
[open,refpage='clRetainDevice',desc='Retain an OpenCL device',type='protos',xrefs='clReleaseDevice']
--
To retain a device, call the function:
include::{generated}/api/protos/clRetainDevice.txt[]
include::{generated}/api/version-notes/clRetainDevice.asciidoc[]
* _device_ is the OpenCL device to retain.
{clRetainDevice} increments the _device_ reference count if _device_ is a
valid sub-device created by a call to {clCreateSubDevices}.
If _device_ is a root level device i.e. a {cl_device_id_TYPE} returned by
{clGetDeviceIDs}, the _device_ reference count remains unchanged.
// refError
{clRetainDevice} returns {CL_SUCCESS} if the function is executed successfully
or the device is a root-level device.
Otherwise, it returns one of the following errors:
* {CL_INVALID_DEVICE} if _device_ is not a valid device.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--
[open,refpage='clReleaseDevice',desc='Release an OpenCL device',type='protos',xrefs='clRetainDevice']
--
To release a device, call the function:
include::{generated}/api/protos/clReleaseDevice.txt[]
include::{generated}/api/version-notes/clReleaseDevice.asciidoc[]
* _device_ is the OpenCL device to retain.
{clReleaseDevice} decrements the _device_ reference count if device is a
valid sub-device created by a call to {clCreateSubDevices}.
If _device_ is a root level device i.e. a {cl_device_id_TYPE} returned by
{clGetDeviceIDs}, the _device_ reference count remains unchanged.
// refError
{clReleaseDevice} returns {CL_SUCCESS} if the function is executed
successfully.
Otherwise, it returns one of the following errors:
* {CL_INVALID_DEVICE} if _device_ is not a valid device.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
After the _device_ reference count becomes zero and all the objects attached
to _device_ (such as command-queues) are released, the _device_ object is
deleted.
Using this function to release a reference that was not obtained by creating
the object or by calling {clRetainDevice} causes undefined behavior.
--
== Contexts
[open,refpage='clCreateContext',desc='Create an OpenCL context',type='protos']
--
To create an OpenCL context, call the function:
include::{generated}/api/protos/clCreateContext.txt[]
include::{generated}/api/version-notes/clCreateContext.asciidoc[]
* _properties_ specifies a list of context property names and their
corresponding values.
Each property name is immediately followed by the corresponding desired
value.
The list is terminated with 0.
The list of supported properties is described in the
<<context-properties-table, Context Properties>> table.
_properties_ can be `NULL` in which case the platform that is selected is
implementation-defined.
* _num_devices_ is the number of devices specified in the _devices_ argument.
* _devices_ is a pointer to a list of unique devices returned by
{clGetDeviceIDs} or sub-devices created by {clCreateSubDevices} for a
platform. footnote:[{fn-duplicate-devices}]
* _pfn_notify_ is a callback function that can be registered by the
application.
This callback function will be used by the OpenCL implementation to report
information on errors during context creation as well as errors that occur
at runtime in this context.
This callback function may be called asynchronously by the OpenCL
implementation.
It is the applications responsibility to ensure that the callback function
is thread-safe.
If _pfn_notify_ is `NULL`, no callback function is registered.
* _user_data_ will be passed as the _user_data_ argument when _pfn_notify_ is
called.
_user_data_ can be `NULL`.
* _errcode_ret_ will return an appropriate error code.
If _errcode_ret_ is `NULL`, no error code is returned.
The parameters to the callback function _pfn_notify_ are:
* _errinfo_ is a pointer to an error string.
* _private_info_ and _cb_ represent a pointer to binary data that is
returned by the OpenCL implementation that can be used to log additional
information helpful in debugging the error.
* _user_data_ is a pointer to user supplied data.
Contexts are used by the OpenCL runtime for managing objects such as
command-queues, memory, program and kernel objects and for executing kernels
on one or more devices specified in the context.
[[context-properties-table]]
.List of supported context creation properties by <<clCreateContext>>
[width="100%",cols="<33%,<17%,<50%",options="header"]
|====
| Context Property | Property Value | Description
| {CL_CONTEXT_PLATFORM_anchor}
include::{generated}/api/version-notes/CL_CONTEXT_PLATFORM.asciidoc[]
| {cl_platform_id_TYPE}
| Specifies the platform to use.
| {CL_CONTEXT_INTEROP_USER_SYNC_anchor}
include::{generated}/api/version-notes/CL_CONTEXT_INTEROP_USER_SYNC.asciidoc[]
| {cl_bool_TYPE}
| Specifies whether the user is responsible for synchronization
between OpenCL and other APIs.
Please refer to the specific sections in the OpenCL Extension
Specification that describe sharing with other APIs for restrictions
on using this flag.
If {CL_CONTEXT_INTEROP_USER_SYNC} is not specified, a default of
{CL_FALSE} is assumed.
|====
NOTE: There are a number of cases where error notifications need to be
delivered due to an error that occurs outside a context.
Such notifications may not be delivered through the _pfn_notify_ callback.
Where these notifications go is implementation-defined.
// refError
{clCreateContext} returns a valid non-zero context and _errcode_ret_ is set
to {CL_SUCCESS} if the context is created successfully.
Otherwise, it returns a `NULL` value with the following error values
returned in _errcode_ret_:
* {CL_INVALID_PLATFORM} if _properties_ is `NULL` and no platform could be
selected or if platform value specified in _properties_ is not a valid
platform.
* {CL_INVALID_PROPERTY} if context property name in _properties_ is not a
supported property name, if the value specified for a supported property
name is not valid, or if the same property name is specified more than
once.
This error code is <<unified-spec, missing before>> version 1.1.
* {CL_INVALID_VALUE} if _devices_ is `NULL`.
* {CL_INVALID_VALUE} if _num_devices_ is equal to zero.
* {CL_INVALID_VALUE} if _pfn_notify_ is `NULL` but _user_data_ is not
`NULL`.
* {CL_INVALID_DEVICE} if any device in _devices_ is not a valid device.
* {CL_DEVICE_NOT_AVAILABLE} if a device in _devices_ is currently not
available even though the device was returned by {clGetDeviceIDs}.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
[NOTE]
====
It is possible that a device(s) becomes unavailable after a context and
command-queues that use this device(s) have been created and commands have
been queued to command-queues.
In this case the behavior of OpenCL API calls that use this context (and
command-queues) are considered to be implementation-defined.
The user callback function, if specified, when the context is created can be
used to record appropriate information in the _errinfo_, _private_info_
arguments passed to the callback function when the device becomes
unavailable.
====
--
[open,refpage='clCreateContextFromType',desc='Create an OpenCL context from a device type',type='protos']
--
To create an OpenCL context from a specific device
type footnote:[{fn-create-context-all-or-subset}], call the function:
include::{generated}/api/protos/clCreateContextFromType.txt[]
include::{generated}/api/version-notes/clCreateContextFromType.asciidoc[]
* _properties_ specifies a list of context property names and their
corresponding values.
Each property name is immediately followed by the corresponding desired
value.
The list of supported properties is described in the
<<context-properties-table, Context Properties>> table.
_properties_ can also be `NULL` in which case the platform that is selected
is implementation-defined.
* _device_type_ is a bit-field that identifies the type of device and is
described in the <<device-types-table, Device Types>> table.
* _pfn_notify_ and _user_data_ are described in {clCreateContext}.
* _errcode_ret_ will return an appropriate error code.
If _errcode_ret_ is `NULL`, no error code is returned.
Only devices that are returned by {clGetDeviceIDs} for _device_type_ are
used to create the context.
The context does not reference any sub-devices that may have been created
from these devices.
// refError
{clCreateContextFromType} returns a valid non-zero context and _errcode_ret_
is set to {CL_SUCCESS} if the context is created successfully.
Otherwise, it returns a `NULL` value with the following error values
returned in _errcode_ret_:
* {CL_INVALID_PLATFORM} if _properties_ is `NULL` and no platform could be
selected or if platform value specified in _properties_ is not a valid
platform.
* {CL_INVALID_PROPERTY} if context property name in _properties_ is not a
supported property name, if the value specified for a supported property
name is not valid, or if the same property name is specified more than
once.
This error code is <<unified-spec, missing before>> version 1.1.
* {CL_INVALID_VALUE} if _pfn_notify_ is `NULL` but _user_data_ is not
`NULL`.
* {CL_INVALID_DEVICE_TYPE} if _device_type_ is not a valid value.
* {CL_DEVICE_NOT_AVAILABLE} if no devices that match _device_type_ and
property values specified in _properties_ are currently available.
* {CL_DEVICE_NOT_FOUND} if no devices that match _device_type_ and property
values specified in _properties_ were found.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--
[open,refpage='clRetainContext',desc='Retain an OpenCL context',type='protos',xrefs='clCreateContext clReleaseContext']
--
To retain a context, call the function:
include::{generated}/api/protos/clRetainContext.txt[]
include::{generated}/api/version-notes/clRetainContext.asciidoc[]
* _context_ specifies the OpenCL context to retain.
{clRetainContext} increments the _context_ reference count.
{clCreateContext} and {clCreateContextFromType} perform an implicit retain.
This is very helpful for 3^rd^ party libraries, which typically get a
context passed to them by the application.
However, it is possible that the application may delete the context without
informing the library.
Allowing functions to attach to (i.e. retain) and release a context solves
the problem of a context being used by a library no longer being valid.
// refError
{clRetainContext} returns {CL_SUCCESS} if the function is executed
successfully.
Otherwise, it returns one of the following errors:
* {CL_INVALID_CONTEXT} if _context_ is not a valid OpenCL context.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--
[open,refpage='clReleaseContext',desc='Release an OpenCL context',type='protos',xrefs='clCreateContext clRetainContext']
--
To release a context, call the function:
include::{generated}/api/protos/clReleaseContext.txt[]
include::{generated}/api/version-notes/clReleaseContext.asciidoc[]
* _context_ specifies the OpenCL context to release.
{clReleaseContext} decrements the _context_ reference count.
After the reference count becomes zero and all the objects attached to
_context_ (such as memory objects, command-queues) are released, the
_context_ is deleted.
Using this function to release a reference that was not obtained by creating
the object or by calling {clRetainContext} causes undefined behavior.
// refError
{clReleaseContext} returns {CL_SUCCESS} if the function is executed
successfully.
Otherwise, it returns one of the following errors:
* {CL_INVALID_CONTEXT} if _context_ is not a valid OpenCL context.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--
[open,refpage='clGetContextInfo',desc='Query information about an OpenCL context',type='protos']
--
To query information about a context, call the function:
include::{generated}/api/protos/clGetContextInfo.txt[]
include::{generated}/api/version-notes/clGetContextInfo.asciidoc[]
* _context_ specifies the OpenCL context being queried.
* _param_name_ is an enumeration constant that specifies the information to
query.
* _param_value_ is a pointer to memory where the appropriate result being
queried is returned.
If _param_value_ is `NULL`, it is ignored.
* _param_value_size_ specifies the size in bytes of memory pointed to by
_param_value_.
This size must be greater than or equal to the size of return type as
described in the <<context-info-table, Context Attributes>> table.
* _param_value_size_ret_ returns the actual size in bytes of data being
queried by _param_name_.
If _param_value_size_ret_ is `NULL`, it is ignored.
The list of supported _param_name_ values and the information returned in
_param_value_ by {clGetContextInfo} is described in the
<<context-info-table, Context Attributes>> table.
[[context-info-table]]
.List of supported param_names by <<clGetContextInfo>>
[width="100%",cols="<33%,<17%,<50%",options="header"]
|====
| Context Info | Return Type | Description
| {CL_CONTEXT_REFERENCE_COUNT_anchor} footnote:[{fn-reference-count-usage}]
include::{generated}/api/version-notes/CL_CONTEXT_REFERENCE_COUNT.asciidoc[]
| {cl_uint_TYPE}
| Return the _context_ reference count.
| {CL_CONTEXT_NUM_DEVICES_anchor}
include::{generated}/api/version-notes/CL_CONTEXT_NUM_DEVICES.asciidoc[]
| {cl_uint_TYPE}
| Return the number of devices in _context_.
| {CL_CONTEXT_DEVICES_anchor}
include::{generated}/api/version-notes/CL_CONTEXT_DEVICES.asciidoc[]
| {cl_device_id_TYPE}[]
| Return the list of devices and sub-devices in _context_.
| {CL_CONTEXT_PROPERTIES_anchor}
include::{generated}/api/version-notes/CL_CONTEXT_PROPERTIES.asciidoc[]
| {cl_context_properties_TYPE}[]
| Return the properties argument specified in {clCreateContext} or
{clCreateContextFromType}.
If the _properties_ argument specified in {clCreateContext} or
{clCreateContextFromType} used to create _context_ was not `NULL`,
the implementation must return the values specified in the
properties argument in the same order and without including
additional properties.
If the _properties_ argument specified in {clCreateContext} or
{clCreateContextFromType} used to create _context_ was `NULL`, the
implementation must return _param_value_size_ret_ equal to 0,
indicating that there are no properties to be returned.
|====
// refError
{clGetContextInfo} returns {CL_SUCCESS} if the function is executed
successfully.
Otherwise, it returns one of the following errors:
* {CL_INVALID_CONTEXT} if _context_ is not a valid context.
* {CL_INVALID_VALUE} if _param_name_ is not one of the supported values or
if size in bytes specified by _param_value_size_ is < size of return
type as specified in the <<context-info-table, Context Attributes>>
table and _param_value_ is not a `NULL` value.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--
[open,refpage='clSetContextDestructorCallback',desc='Registers a destructor callback function with a context.',type='protos']
--
To register a callback function with a context that is called when
the context is destroyed, call the function
include::{generated}/api/protos/clSetContextDestructorCallback.txt[]
include::{generated}/api/version-notes/clSetContextDestructorCallback.asciidoc[]
* _context_ specifies the OpenCL context to register the callback to.
* _pfn_notify_ is the callback function to register.
This callback function may be called asynchronously by the OpenCL
implementation.
It is the application's responsibility to ensure that the callback function
is thread-safe.
The parameters to this callback function are:
** _context_ is the OpenCL context being deleted.
When the callback function is called by the implementation, this context
is no longer valid.
_context_ is only provided for reference purposes.
** _user_data_ is a pointer to user-supplied data.
* _user_data_ will be passed as the _user_data_ argument when _pfn_notify_ is
called.
_user_data_ can be `NULL`.
Each call to {clSetContextDestructorCallback} registers the specified
callback function on a destructor callback stack associated with _context_.
The registered callback functions are called in the reverse order in
which they were registered.
If a context callback function was specified when _context_ was created,
it will not be called after any context destructor callback is called.
Therefore, the context destructor callback provides a mechanism for an
application to safely re-use or free any _user_data_ specified for the
context callback function when _context_ was created.
// refError
{clSetContextDestructorCallback} returns {CL_SUCCESS} if the function is
executed successfully.
Otherwise, it returns one of the following errors:
* {CL_INVALID_CONTEXT} if _context_ is not a valid context.
* {CL_INVALID_VALUE} if _pfn_notify_ is `NULL`.
* {CL_OUT_OF_RESOURCES} if there is a failure to allocate resources required
by the OpenCL implementation on the device.
* {CL_OUT_OF_HOST_MEMORY} if there is a failure to allocate resources
required by the OpenCL implementation on the host.
--