The spec isn't fully generalized for arbitrary CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS
For param_name of CL_KERNEL_GLOBAL_WORK_SIZE, the table in the description of clGetKernelWorkGroupInfo specifies "return type" size_t[3] and contains the following description:
This provides a mechanism for the application to query the maximum global size that can be used to execute a kernel (i.e. the global_work_size argument to
clEnqueueNDRangeKernel) on a custom device given by device or a built-in kernel on an OpenCL device given by device.If device is not a custom device and kernel is not a built-in kernel,
clGetKernelWorkGroupInforeturns the errorCL_INVALID_VALUE.
It isn't clear what is the return value in case CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS for device isn't 3, which, per specification, is possible. In particular:
- When
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS > 3, the return value doesn't fit in the "return type". - When
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS < 3(possible for custom devices) it isn't clear which elements of the returnedsize_t[3]correspond to actual dimensions and what the rest of the elements are.
CL_KERNEL_COMPILE_WORK_GROUP_SIZE has a similar problem and is the only other place where size_t[3] return type is found.
Note that, e.g., for CL_DEVICE_MAX_WORK_ITEM_SIZES the "return type" (size_t[]) and description are properly generalized:
Maximum number of work-items that can be specified in each dimension of the work-group to
clEnqueueNDRangeKernel.Returns n
size_tentries, where n is the value returned by the query forCL_DEVICE_MAX_WORK_ITEM_DIMENSIONS.The minimum value is (1, 1, 1) for devices that are not of type
CL_DEVICE_TYPE_CUSTOM.
However, there's an additional (minor) issue here: the n-element minimum value is specified as 3-element list, whereas in some other places, like "The starting local ID is always (0, 0, …, 0)" in the description of clEnqueueNDRangeKernel, the n-element lists are specified using ellipsis. In general, there's an inconsistency in how n-element lists are specified.