Added fp16 and fp64 api consistency tests #2058
Conversation
| error = clGetDeviceInfo(deviceID, CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE, | ||
| sizeof(value), &value, nullptr); | ||
| test_error(error, | ||
| "Unable to get device CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE"); | ||
| test_assert_error( | ||
| value > 0, | ||
| "CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE must return nonzero value"); |
There was a problem hiding this comment.
So we go in with eyes open: this change requires CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE to be non-zero when fp64 is supported. This is true even if there is no "native" double precision support, say when CL_DEVICE_DOUBLE_FP_CONFIG includes CL_FP_SOFT_FLOAT.
No action required, but if we did want to "fix" this, some options might be:
- Remove the check entirely - the spec doesn't have any requirements for a value for
CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLEwhen fp64 is supported. Note, there is a requirement when fp64 is NOT supported, so this check should not change. - Have the check only when
CL_DEVICE_DOUBLE_FP_CONFIGdoes not includeCL_FP_SOFT_FLOAT, since there should be some "native" support in this case.
Same comments also apply to fp16.
There was a problem hiding this comment.
Discussed in the October 1st teleconference. We are going to leave this as-is for now. We will revisit in the future, if needed, if a vendor wants to return zero for CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE and still support fp64 for some reason.
|
Merging as discussed in the October 1st teleconference. |
| { | ||
| error = clGetDeviceInfo(deviceID, CL_DEVICE_HALF_FP_CONFIG, | ||
| sizeof(value), &value, nullptr); | ||
| test_error(error, "Unable to get device CL_DEVICE_HALF_FP_CONFIG"); |
There was a problem hiding this comment.
This requires implementations without the cl_khr_fp16 extension to recognise CL_DEVICE_HALF_FP_CONFIG, but support for CL_DEVICE_HALF_FP_CONFIG is only required if that extension is available, is it not? https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#CL_DEVICE_HALF_FP_CONFIG says "provided by the cl_khr_fp16 extension". Our implementation, when FP16 support is disabled, returns CL_INVALID_VALUE here rather than setting value to 0, and I think that is correct, since the spec also says it returns:
CL_INVALID_VALUE if param_name is not one of the supported values or if size in bytes specified by param_value_size is < size of return type as specified in the Device Queries table and param_value is not a NULL value or if param_name is a value that is available as an extension and the corresponding extension is not supported by the device.
There was a problem hiding this comment.
@hvdijk I agree with your analysis. CL_DEVICE_HALF_FP_CONFIG is provided by the cl_khr_fp16 extension, so if that extension is not supported the query should return CL_INVALID_VALUE indeed.
(the half query seems different from CL_DEVICE_DOUBLE_FP_CONFIG, which does not have a "provided by" clause)
There was a problem hiding this comment.
Thanks, created #2108 to change that.
#1578