KhronosGroup / KhronosGroup/OpenCL-Docs
remove unavoidable error conditions
- Dominant language
- Python
- Stars
- 420
- Forks
- 131
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 11
Description
Philosophically, it should be possible for a well-written OpenCL program to execute without generating any OpenCL errors. This means that no error conditions should be "unavoidable", where the only way to determine if an operation will be successful is to try making an API call and then check the returned error code.
This issue is to document places in the OpenCL spec where there are currently "unavoidable" error conditions and to document how to remove them. This will likely need to be done in a minor OpenCL API revision, since it is a change to specified behavior.
1. `clGetPlatformIDs` returns `CL_PLATFORM_NOT_FOUND_KHR` if the `cl_khr_icd` extension is supported and zero platforms are available.
* Why couldn't this just return `CL_SUCCESS` and `num_platforms` equal to zero, instead?
2. `clGetDeviceIDs` returns `CL_DEVICE_NOT_FOUND` if no devices in the platform match the requested device type.
* This is true even for `CL_DEVICE_TYPE_ALL`.
* Why couldn't this just return `CL_SUCCESS` and `num_devices` equal to zero, instead?
Contributor guide
Research direction
Start by reviewing the OpenCL specification sections for clGetPlatformIDs and clGetDeviceIDs, including the cl_khr_icd behavior and device-type cases listed here. Identify every currently unavoidable error condition and the specified behavior changes needed to remove them; done means the affected cases and removal path are documented clearly enough to inform a minor API revision.
Written by the indexing model from the issue text.
Assessment
- Domain
- api, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100