KhronosGroup / KhronosGroup/OpenCL-CLHPP
Invalid call to clGetKernelWorkGroupInfo?
- Dominant language
- C++
- Stars
- 425
- Forks
- 133
- Avg merge
- 3h 30m
- Merged PRs (30d)
- 1
Description
When calling `kernel.getWorkGroupInfo(device, &err)`, this will lead to https://github.com/KhronosGroup/OpenCL-CLHPP/blob/master/input_cl2.hpp#L1052:
``` cpp
// Specialized GetInfoHelper for clsize_t params
template
inline cl_int getInfoHelper(Func f, cl_uint name, array* param, long)
{
size_type required;
cl_int err = f(name, 0, NULL, &required);
if (err != CL_SUCCESS) {
return err;
}
```
When I run this with the latest Intel OpenCL runtime for Core & Xeon (version 16.1.1) CPUs, the `required` variable will get 0 written to it, subsequently resulting in no values being written to the return array. Instead the return array is left uninitialized, which is clearly broken.
And actually, according to [the spec](https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clGetKernelWorkGroupInfo.html), this is the correct behavior:
> param_value_size_ret
> Returns the actual size in bytes of data copied to param_value. If param_value_size_ret is NULL, it is ignored.
Note that it says "actual size in bytes of data copied to param_value", not "the actual size in bytes of data being queried by param_value" that is the case for e.g. clGetPlatformInfo.
Since it is known exactly how much space is needed statically, the simple fix seems to be removing the "required" check:
``` cpp
// Specialized GetInfoHelper for clsize_t params
template
inline cl_int getInfoHelper(Func f, cl_uint name, array* param, long)
{
size_type required = N * sizeof(size_type);
cl_int err = f(name, required, param->data(), NULL);
if (err != CL_SUCCESS) {
return err;
}
return CL_SUCCESS;
}
```
If this is not acceptable, then a special case would be needed for clGetKernelWorkGroupInfo, and possibly others.
Contributor guide
No contributing guide indexed for this repository
Research direction
Review input_cl2.hpp around line 1052 and the clGetKernelWorkGroupInfo call path. Check the OpenCL specification's param_value_size_ret semantics against the reported Intel runtime behavior, then verify that the chosen handling populates the returned work-group-size array instead of leaving it uninitialized.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- api
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100