ocl-icd
ocl-icd copied to clipboard
Do not use default platform unless it is explicitly set
Thanks for the pull request. I'll be reevaluating the NULL platform behavior once we revisit it in the OpenCL WG.
Thanks @Kerilk. This behavior is conflicting with this test: https://github.com/KhronosGroup/OpenCL-CTS/blob/master/test_conformance/compiler/test_unload_platform_compiler.cpp#L397
The way I see it, I do not think a nullptr could be considered a valid platform so this feature (replacing nullptr with default platform) being enabled "out of the box" seems to not be in line with the OCL specification.
This is a copy paste from this post for more context: https://github.com/KhronosGroup/OpenCL-ICD-Loader/pull/114#issuecomment-669625963
This behavior has always seemed incoherent to me with the content of the extension: https://github.com/KhronosGroup/OpenCL-Docs/blob/master/ext/cl_khr_icd.asciidoc#L334-L344 which state:
How will the ICD handle a NULL cl_platform_id?
RESOLVED: The ICD will by default choose the first enumerated platform as the NULL platform. The user can override this default by setting an environment variable OPENCL_ICD_DEFAULT_PLATFORM to the desired platform index. The API calls that deal with platforms will return CL_INVALID_PLATFORM if the index is not between zero and (number of platforms - 1), both inclusive.
I know the wording is strange but always believed ICD was ICD loader in this paragraph.
So my understanding is that this should not be implementation defined, and that the previous behavior of the (official) loader was not correct. In the case of clCreateContext it could be argued that if the user provided a platform it should be used for dispatch. If the user provided a NULL platform, maybe it should be considered the default platform (I noticed this last case is not correctly handled in ocl-icd).
That is why we need to revisit the way loaders deal with the NULL platform.