Pass additional information other than argument values to a kernel.
cl_int clSetKernelExecInfo(cl_kernel kernel, cl_kernel_exec_info param_name, size_t param_value_size, const void *param_value)
Specifies the kernel object being queried.
Specifies the information to be passed to
kernel. The list of supported
param_nametypes and the corresponding values passed in
param_valueis described in the table below.
Specifies the size in bytes of the memory pointed to by
A pointer to memory where the appropriate values determined by
cl_kernel_exec_info Type and Description
Type: void *
SVM pointers used by a kernel which are not passed as arguments to
kernel. These addresses may be defined in SVM buffer(s) that are passed as arguments to
These non-argument SVM pointers must be specified using
clSetKernelExecInfofor coarse-grain and fine-grain buffer SVM allocations but not for fine-grain system SVM allocations.
This flag indicates whether the kernel uses pointers that are fine grain system SVM allocations. These fine grain system SVM pointers may be passed as arguments or defined in SVM buffers that are passed as argumentsto
Coarse-grain or fine-grain buffer SVM pointers used by a kernel which are not passed as a kernel arguments must be specified using
For example, if SVM buffer A contains a pointer to another SVM buffer B, and the kernel dereferences that pointer, then a pointer to B must either be passed as an argument in the call to that kernel or it must be made available to the kernel using
For example, we might pass extra SVM pointers as follows:
clSetKernelExecInfo(kernel, CL_KERNEL_EXEC_INFO_SVM_PTRS, num_ptrs * sizeof(void *), extra_svm_ptr_list);
num_ptrs specifies the number of additional SVM pointers while
extra_svm_ptr_list specifies a pointer to memory containing those SVM pointers.
CL_KERNEL_EXEC_INFO_SVM_PTRS to specify pointers to non-argument SVM buffers as extra arguments to a kernel, each of these pointers can be the SVM pointer returned by
clSVMAlloc or can be a pointer + offset into the SVM region.
It is sufficient to provide one pointer for each SVM buffer used.
CL_KERNEL_EXEC_INFO_SVM_FINE_GRAIN_SYSTEM is used to indicate whether SVM pointers used by a kernel will refer to system allocations or not.
CL_FALSE indicates that the OpenCL implementation may assume that system pointers are not passed as kernel arguments and are not stored inside SVM allocations passed as kernel arguments.
CL_TRUE indicates that the OpenCL implementation must assume that system pointers might be passed as kernel arguments and/or stored inside SVM allocations passed as kernel arguments.
In this case, if the device to which the kernel is enqueued does not support system SVM pointers,
clEnqueueNDRangeKernel will return a
If none of the devices in the context associated with kernel support fine-grain system SVM allocations,
clSetKernelExecInfo will return a
clSetKernelExecInfo has not been called with a value for
CL_KERNEL_EXEC_INFO_SVM_FINE_GRAIN_SYSTEM the default value is used for this kernel attribute.
The defaule value depends on whether the device on which the kernel is enqueued supports fine-grain system SVM allocations.
If so, the default value used is
CL_TRUE (system pointers might be passed); otherwise, the default is
A call to
clSetKernelExecInfo for a given value of
param_name replaces any prior value passed for that value of
param_value will be stored for each value of
An OpenCL API call is considered to be thread-safe if the internal state as managed by OpenCL remains consistent when called simultaneously by multiple host threads. OpenCL API calls that are thread-safe allow an application to call these functions in multiple host threads without having to implement mutual exclusion across these host threads i.e. they are also re-entrant-safe.
clCloneKernel are safe to call from any host thread, and safe to call re-entrantly so long as concurrent calls to any combination of these API calls operate on different cl_kernel objects.
The state of the cl_kernel object is undefined if
clCloneKernel are called from multiple host threads on the same cl_kernel object at the same time.
Please note that there are additional limitations as to which OpenCL APIs may be called from OpenCL callback functions — please see section 5.11.
The behavior of OpenCL APIs called from an interrupt or signal handler is implementation-defined.
There is an inherent race condition in the design of OpenCL that occurs between setting a kernel argument and using the kernel with
Another host thread might change the kernel arguments between when a host thread sets the kernel arguments and then enqueues the kernel, causing the wrong kernel arguments to be enqueued.
Rather than attempt to share
cl_kernel objects among multiple host threads, applications are strongly encouraged to make additional
cl_kernel objects for kernel functions for each host thread.
CL_SUCCESS if the function is executed successfully.
Otherwise, it returns one of the following errors:
kernelis not a valid kernel object.
param_nameis not valid, if
param_valueis NULL or if the size specified by
param_value_sizeis not valid.
CL_TRUEbut no devices in context associated with
kernelsupport fine-grain system SVM allocations.
CL_OUT_OF_RESOURCESif there is a failure to allocate resources required by the OpenCL implementation on the device.
CL_OUT_OF_HOST_MEMORYif there is a failure to allocate resources required by the OpenCL implementation on the host.