-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should binary_status[i]
be set in clCreateProgramWithBinary if lengths[i]
is zero or binaries[i]
is NULL?
#1203
Comments
Hi, good question! It looks like our implementation will return It would probably be good to hear how other vendors have interpreted the spec here. Do you have a preference between your two options? |
Rusticl does set
My personal preference would be to not set Setting any |
Cool, this aligns with the discussion in today's OpenCL teleconference, where we also observed that an application (or a debug layer) could check whether the size is zero or the binary is NULL, but cannot check whether a non-NULL binary is valid for a specific device. We didn't reach a conclusion today, but maybe we're getting close.
When multiple errors occur we generally do not specificy which should be returned, so my first reaction is that it would be correct to return either error. I suspect most implementations would check for a NULL binary first and hence would hence return |
Hi
Suppose that
(lengths[i] == 0 || binaries[i] == NULL) && binary_status != NULL
in clCreateProgramWithBinary.Should
binary_status[i]
be set to CL_INVALID_VALUE in that case?The spec currently says:
If yes, it would be good to add the sentence "binary_status will return specific status for each device." to the documentation of the CL_INVALID_VALUE return value and to add "in binary_status[i]" to CL_INVALID_VALUE within the documentation of binary_status.
If no, it would be clearer to remove any mention CL_INVALID_VALUE from the documentation of binary_status.
The text was updated successfully, but these errors were encountered: