opencl_platform_layer.asciidoc

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

The list of platforms available can be obtained with the function:

{generated}/api/protos/clGetPlatformIDs.txt {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, 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.

{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

  • 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

Specific information about an OpenCL platform can be obtained with the function:

{generated}/api/protos/clGetPlatformInfo.txt {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.

• param_value is a pointer to memory location where appropriate values for a given param_name, as specified in the 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 must be greater than or equal to the size of the return type specified in the Platform Queries table. If param_value is NULL, it is ignored.

• 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.

Table 1. List of supported param_names by {clGetPlatformInfo}

Platform Info	Return Type	Description
{CL_PLATFORM_PROFILE_anchor} [1] {generated}/api/version-notes/CL_PLATFORM_PROFILE.asciidoc	{char_TYPE}[] [2]	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.
{CL_PLATFORM_VERSION_anchor} {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} {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} {generated}/api/version-notes/CL_PLATFORM_NAME.asciidoc	{char_TYPE}[]	Platform name string.
{CL_PLATFORM_VENDOR_anchor} {generated}/api/version-notes/CL_PLATFORM_VENDOR.asciidoc	{char_TYPE}[]	Platform vendor string.
{CL_PLATFORM_EXTENSIONS_anchor} {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} {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} {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 platforms that do not support device and host timer synchronization.

{clGetPlatformInfo} returns {CL_SUCCESS} if the function is executed successfully. Otherwise, it returns one of the following errors ^[3].

• {CL_INVALID_PLATFORM}

  • if platform is not a valid platform

• {CL_INVALID_VALUE}

  • if param_name is not one of the supported values

  • if the size in bytes specified by param_value_size is less than the size of the return type specified in the Platform Queries table and param_value is not NULL

• {CL_OUT_OF_HOST_MEMORY}

  • if there is a failure to allocate resources required by the OpenCL implementation on the host

Querying Devices

The list of devices available on a platform can be obtained using the function ^[4]:

{generated}/api/protos/clGetDeviceIDs.txt {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.

• 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.

Table 2. List of supported device_types by {clGetDeviceIDs}

Device Type	Description
{CL_DEVICE_TYPE_CPU_anchor} {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} {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} {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} {generated}/api/version-notes/CL_DEVICE_TYPE_CUSTOM.asciidoc	Specialized devices that support a subset of the OpenCL runtime APIs for directed tasks but are not OpenCL conformant. A custom device must implement all of the OpenCL runtime APIs, but may not support all of the required minimum device capabilities and may return implementation-defined error codes for unsupported functionality.
{CL_DEVICE_TYPE_DEFAULT_anchor} {generated}/api/version-notes/CL_DEVICE_TYPE_DEFAULT.asciidoc	The default OpenCL device in the platform. One device in the platform must be returned as the {CL_DEVICE_TYPE_DEFAULT} device when passed as the device_type to {clGetDeviceIDs}. {CL_DEVICE_TYPE_DEFAULT} is only used to query OpenCL devices using {clGetDeviceIDs} or to create OpenCL contexts using {clCreateContextFromType}, and will never be returned in {CL_DEVICE_TYPE} for any OpenCL device. The default OpenCL device must not be a {CL_DEVICE_TYPE_CUSTOM} device unless it is the only device in the platform.
{CL_DEVICE_TYPE_ALL_anchor} {generated}/api/version-notes/CL_DEVICE_TYPE_ALL.asciidoc	All OpenCL devices in the platform. {CL_DEVICE_TYPE_ALL} is only used to query OpenCL devices using {clGetDeviceIDs} or to create OpenCL contexts using {clCreateContextFromType}, and will never be returned in {CL_DEVICE_TYPE} for any OpenCL device.

{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

  • 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.

To get specific information about an OpenCL device, call the function:

{generated}/api/protos/clGetDeviceInfo.txt {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.

• 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.

• param_value is a pointer to memory location where appropriate values for a given param_name, as specified in the 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 must be greater than or equal to the size of the return type specified in the Device Queries table. If param_value is NULL, it is ignored.

• 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 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}

Table 3. List of supported param_names by {clGetDeviceInfo}

Device Info	Return Type	Description
{CL_DEVICE_TYPE_anchor} {generated}/api/version-notes/CL_DEVICE_TYPE.asciidoc	{cl_device_type_TYPE}	The type of the OpenCL device. The device type is purely informational and has no semantic meaning. The device must report a single device type, which must not be {CL_DEVICE_TYPE_DEFAULT} or {CL_DEVICE_TYPE_ALL}. Please see the Device Types table for supported device types and device type descriptions.
{CL_DEVICE_VENDOR_ID_anchor} [5] {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} {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} {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.
{CL_DEVICE_MAX_WORK_ITEM_SIZES_anchor} {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).
{CL_DEVICE_MAX_WORK_GROUP_SIZE_anchor} {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} {CL_DEVICE_PREFERRED_VECTOR_WIDTH_HALF} is 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_EXT} 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} {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_EXT} extension is not supported, {CL_DEVICE_NATIVE_VECTOR_WIDTH_HALF} must return 0.
{CL_DEVICE_MAX_CLOCK_FREQUENCY_anchor} {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 missing before version 2.2. Maximum configured clock frequency of the device in MHz. Note: This definition is deprecated by version 2.2.
{CL_DEVICE_ADDRESS_BITS_anchor} {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} {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/4th of {CL_DEVICE_GLOBAL_MEM_SIZE}), 32 {times} 1024 {times} 1024).
{CL_DEVICE_IMAGE_SUPPORT_anchor} {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} [6] {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} {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} {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} {generated}/api/version-notes/CL_DEVICE_IL_VERSION.asciidoc	{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} {generated}/api/version-notes/CL_DEVICE_ILS_WITH_VERSION.asciidoc	{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} {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} {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} {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} {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} {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} {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} {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} {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} {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} {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} {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} {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} {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} {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 this minimum value, only a maximum of 128 arguments can be passed to a kernel. For all other values, a maximum of 255 arguments can be passed to a kernel.
{CL_DEVICE_MEM_BASE_ADDR_ALIGN_anchor} {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).
{CL_DEVICE_MIN_DATA_TYPE_ALIGN_SIZE_anchor} {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} [7] {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} - the fma kernel builtin is implemented using hardware-accelerated fused multiply-add as defined in IEEE754-2008. {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 is: {CL_FP_ROUND_TO_NEAREST} | {CL_FP_INF_NAN}. For the embedded profile, see the dedicated table.
{CL_DEVICE_DOUBLE_FP_CONFIG_anchor} [7] {generated}/api/version-notes/CL_DEVICE_DOUBLE_FP_CONFIG.asciidoc Also see {cl_khr_fp64_EXT}.	{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} - the fma kernel builtin is implemented using hardware-accelerated fused multiply-add as defined in IEEE754-2008. {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 for OpenCL 2.0 or newer devices is: {CL_FP_FMA} | {CL_FP_ROUND_TO_NEAREST} | {CL_FP_INF_NAN} | {CL_FP_DENORM}. or for OpenCL 1.0, OpenCL 1.1 or OpenCL 1.2 devices: {CL_FP_FMA} | {CL_FP_ROUND_TO_NEAREST} | {CL_FP_ROUND_TO_ZERO} | {CL_FP_ROUND_TO_INF} | {CL_FP_INF_NAN} | {CL_FP_DENORM}.
{CL_DEVICE_GLOBAL_MEM_CACHE_TYPE_anchor} {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} {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} {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} {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} {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.
{CL_DEVICE_MAX_CONSTANT_ARGS_anchor} {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.
{CL_DEVICE_MAX_GLOBAL_VARIABLE_SIZE_anchor} {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} {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} {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} {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.
{CL_DEVICE_ERROR_CORRECTION_SUPPORT_anchor} {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} {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} {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 for details.
{CL_DEVICE_ENDIAN_LITTLE_anchor} {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} {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} {generated}/api/version-notes/CL_DEVICE_COMPILER_AVAILABLE.asciidoc	{cl_bool_TYPE}	Is {CL_TRUE} if a compiler is available to compile programs created from source or IL, or {CL_FALSE} if the implementation does not have a compiler available. This must be {CL_TRUE} for devices supporting the full profile. When an online compiler is not available, OpenCL programs may still be created from binaries or built-in kernels supported by the device.
{CL_DEVICE_LINKER_AVAILABLE_anchor} {generated}/api/version-notes/CL_DEVICE_LINKER_AVAILABLE.asciidoc	{cl_bool_TYPE}	Is {CL_TRUE} if a linker is available to link compiled programs, or {CL_FALSE} if the implementation does not have a linker available. This must be {CL_TRUE} for devices supporting the full profile or if {CL_DEVICE_COMPILER_AVAILABLE} is {CL_TRUE}.
{CL_DEVICE_EXECUTION_CAPABILITIES_anchor} {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} {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} {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. The mandated minimum capability is: {CL_QUEUE_PROFILING_ENABLE}.
{CL_DEVICE_QUEUE_ON_DEVICE_PROPERTIES_anchor} {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. 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} {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} {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} {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} {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} {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} {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} {generated}/api/version-notes/CL_DEVICE_PLATFORM.asciidoc	{cl_platform_id_TYPE}	The platform associated with this device.
{CL_DEVICE_NAME_anchor} {generated}/api/version-notes/CL_DEVICE_NAME.asciidoc	{char_TYPE}[]	Device name string.
{CL_DEVICE_VENDOR_anchor} {generated}/api/version-notes/CL_DEVICE_VENDOR.asciidoc	{char_TYPE}[]	Vendor name string.
{CL_DRIVER_VERSION_anchor} {generated}/api/version-notes/CL_DRIVER_VERSION.asciidoc	{char_TYPE}[]	OpenCL software driver version string. Follows a vendor-specific format.
{CL_DEVICE_PROFILE_anchor} {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} {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} {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} {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} {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} {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} {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_EXT} {cl_khr_global_int32_base_atomics_EXT} {cl_khr_global_int32_extended_atomics_EXT} {cl_khr_local_int32_base_atomics_EXT} {cl_khr_local_int32_extended_atomics_EXT} 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_EXT} 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_EXT} {cl_khr_depth_images_EXT} {cl_khr_image2d_from_buffer_EXT} Please refer to the OpenCL Specification or vendor-provided documentation for a detailed description of these extensions.
{CL_DEVICE_EXTENSIONS_WITH_VERSION_anchor} {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} for a list of extensions that are required to be reported for a given OpenCL version.
{CL_DEVICE_PRINTF_BUFFER_SIZE_anchor} {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} {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} {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} {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} {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 sub-devices), a value of 0 will be returned.
{CL_DEVICE_PARTITION_AFFINITY_DOMAIN_anchor} {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} {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} [8] {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} {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} {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} {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} {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} {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 sub-groups, and must be 0 for devices that do not support sub-groups. Support for sub-groups is required for an OpenCL 2.1 or 2.2 device. (Refer also to {clGetKernelSubGroupInfo}.)
{CL_DEVICE_SUB_GROUP_INDEPENDENT_FORWARD_PROGRESS_anchor} {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_EXT} extension, and must return {CL_FALSE} for devices that do not support sub-groups.
{CL_DEVICE_ATOMIC_MEMORY_CAPABILITIES_anchor} {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} [9] - 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} A device that does not support {CL_DEVICE_SVM_ATOMICS} (and hence does not support {CL_MEM_SVM_ATOMICS}) may still support {CL_DEVICE_ATOMIC_SCOPE_ALL_DEVICES}. On these devices, an atomic operation with memory_scope_all_svm_devices will behave the same as if the scope were memory_scope_device - refer to the memory consistency model.
{CL_DEVICE_ATOMIC_FENCE_CAPABILITIES_anchor} {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} {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.
{CL_DEVICE_WORK_GROUP_COLLECTIVE_FUNCTIONS_SUPPORT_anchor} {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.
{CL_DEVICE_GENERIC_ADDRESS_SPACE_SUPPORT_anchor} {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.
{CL_DEVICE_DEVICE_ENQUEUE_CAPABILITIES_anchor} {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}.
{CL_DEVICE_PIPE_SUPPORT_anchor} {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}.
{CL_DEVICE_PREFERRED_WORK_GROUP_SIZE_MULTIPLE_anchor} {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} {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.

{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

  • if the size in bytes specified by param_value_size is less than the size of the return type specified in the Device Queries table and param_value is not 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

To query device and host timestamps, call the function:

{generated}/api/protos/clGetDeviceAndHostTimer.txt {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.

{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 is NULL

  • if 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

To query the host clock, call the function:

{generated}/api/protos/clGetHostTimer.txt {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 missing before version 1.2.

To create sub-devices partitioning an OpenCL device, call the function:

{generated}/api/protos/clCreateSubDevices.txt {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 Sub-device 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.

Table 4. List of supported partition schemes by {clCreateSubDevices}

Partition Property	Partition Value	Description
{CL_DEVICE_PARTITION_EQUALLY_anchor} {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} {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} {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.

{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

  • if values specified in properties are valid but not are supported by in_device

  • 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}

  • if the total number of compute units requested exceeds {CL_DEVICE_MAX_COMPUTE_UNITS} for in_device

  • if the number of compute units requested for one or more sub-devices is less than zero

  • if the number of sub-devices requested for one or more sub-devices 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:

{ 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:

{ 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:

{ CL_DEVICE_PARTITION_BY_AFFINITY_DOMAIN,
    CL_DEVICE_AFFINITY_DOMAIN_NEXT_PARTITIONABLE,
  0 } // 0 terminates the property list

To retain a device, call the function:

{generated}/api/protos/clRetainDevice.txt {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.

{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

To release a device, call the function:

{generated}/api/protos/clReleaseDevice.txt {generated}/api/version-notes/clReleaseDevice.asciidoc

• device is the OpenCL device to release.

{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.

{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

To create an OpenCL context, call the function:

{generated}/api/protos/clCreateContext.txt {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, and their default values if not present in properties, is described in the Context Properties table. properties can be NULL, in which case all properties take on their default values.

• 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. ^[10]

• 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 application’s 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.

Table 5. List of supported context creation properties by {clCreateContext}

Context Property	Property Value	Description
{CL_CONTEXT_PLATFORM_anchor} {generated}/api/version-notes/CL_CONTEXT_PLATFORM.asciidoc	{cl_platform_id_TYPE}	Specifies the platform to use. Defaults to an implementation-defined platform if not specified.
{CL_CONTEXT_INTEROP_USER_SYNC_anchor} {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 Specification that describe sharing with other APIs for restrictions on using this flag. Defaults to {CL_FALSE} if not specified.

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.

{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 no platform is specified in properties and no platform could be selected

  • if the platform specified in properties is not a valid platform

• {CL_INVALID_PROPERTY}

  • if a context property name in properties is not a supported property name

  • if the value specified for a supported property name is not valid

  • if the same property name is specified more than once

• {CL_INVALID_VALUE}

  • if devices is NULL

  • if num_devices is equal to zero

  • if pfn_notify is NULL and 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

• {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 and private_info arguments passed to the callback function when the device becomes unavailable.

To create an OpenCL context from a specific device type ^[11], call the function:

{generated}/api/protos/clCreateContextFromType.txt {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, and their default values if not present in properties, is described in the Context Properties table. properties can be NULL, in which case all properties take on their default values.

• device_type is a bit-field that identifies the type of device and is described in the 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.

{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 no platform is specified in properties and no platform could be selected

  • if the platform specified in properties is not a valid platform

• {CL_INVALID_PROPERTY}

  • if a context property name in properties is not a supported property name

  • if the value specified for a supported property name is not valid

  • if the same property name is specified more than once

• {CL_INVALID_VALUE}

  • if pfn_notify is NULL and 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

To retain a context, call the function:

{generated}/api/protos/clRetainContext.txt {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.

{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

To release a context, call the function:

{generated}/api/protos/clReleaseContext.txt {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. When the context is deleted, any commands associated with the context that have not completed may be abnormally terminated. Using this function to release a reference that was not obtained by creating the object or by calling {clRetainContext} causes undefined behavior.

{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

To query information about a context, call the function:

{generated}/api/protos/clGetContextInfo.txt {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 the return type specified in the Context Queries table. If param_value is NULL, it is ignored.

• 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 Queries table.

Table 6. List of supported param_names by {clGetContextInfo}

Context Info	Return Type	Description
{CL_CONTEXT_REFERENCE_COUNT_anchor} [12] {generated}/api/version-notes/CL_CONTEXT_REFERENCE_COUNT.asciidoc	{cl_uint_TYPE}	Return the context reference count.
{CL_CONTEXT_NUM_DEVICES_anchor} {generated}/api/version-notes/CL_CONTEXT_NUM_DEVICES.asciidoc	{cl_uint_TYPE}	Return the number of devices in context.
{CL_CONTEXT_DEVICES_anchor} {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} {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.

{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

  • if the size in bytes specified by param_value_size is less than the size of the return type specified in the Context Queries table and param_value is not 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

To register a callback function with a context that is called when the context is destroyed, call the function

{generated}/api/protos/clSetContextDestructorCallback.txt {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.

{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

Extension Function Pointers

Extension function pointers for a given platform can be obtained with the function:

{generated}/api/protos/clGetExtensionFunctionAddressForPlatform.txt {generated}/api/version-notes/clGetExtensionFunctionAddressForPlatform.asciidoc

Or, with the function:

{generated}/api/protos/clGetExtensionFunctionAddress.txt {generated}/api/version-notes/clGetExtensionFunctionAddress.asciidoc

The returned function pointer should be cast to a function pointer type matching the extension function’s definition defined in the appropriate extension specification and header file.

A return value of NULL indicates that platform is not a valid platform or that the specified extension function does not exist for the platform.

A non-NULL return value from {clGetExtensionFunctionAddressForPlatform} does not guarantee that an extension function is actually supported by the platform. The application must also query {CL_PLATFORM_EXTENSIONS} or {CL_DEVICE_EXTENSIONS} to determine if an extension is supported by an OpenCL platform or device.

Since there is no way to qualify the {clGetExtensionFunctionAddressForPlatform} query with a device, the function pointer returned must work for all implementations of and extension on different devices for a platform. The behavior of calling a device extension function on a device not supporting that extension is undefined.

{clGetExtensionFunctionAddressForPlatform} may not be used to query for core (non-extension) functions in OpenCL. For extension functions queried using {clGetExtensionFunctionAddressForPlatform}, implementations may also choose to export those functions statically from the object libraries implementing those functions, however, portable applications cannot rely on this behavior.

---

1. {fn-platform-profile}

2. {fn-null-terminated-string}

3. {fn-error-precedence}

4. {fn-get-device-ids-all-or-subset}

5. {fn-vendor-id}

6. {fn-max-read-image-args}

7. {fn-native-rounding-modes}

8. {fn-reference-count-usage}

9. {fn-atomic-scope-work-item}

10. {fn-duplicate-devices}

11. {fn-create-context-all-or-subset}

12. {fn-reference-count-usage}