Added test to verify API consistency when linker or compiler unavailable#2630
Added test to verify API consistency when linker or compiler unavailable#2630shajder wants to merge 2 commits intoKhronosGroup:mainfrom
Conversation
| if (!compilerAvail) | ||
| { | ||
| cl_uint specConst = 42; | ||
| error = clSetProgramSpecializationConstant( | ||
| program, 0, sizeof(specConst), &specConst); |
There was a problem hiding this comment.
Can you describe what this case is testing in more detail?
If we get here there's something in the string returned by CL_DEVICE_IL_VERSION or the array returned by CL_DEVICE_ILS_WITH_VERSION, so it would be odd to return that a compiler is unavailable. If anything, it seems like we should test that a compiler is available in this case, otherwise how would you compile the programs created from a supported IL?
Regardless, we haven't created program for the call to clSetProgramSpecializationConstant, so I think we would need to accept CL_INVALID_PROGRAM or a bunch of other error conditions, not just CL_COMPILER_NOT_AVAILABLE.
There was a problem hiding this comment.
Hmm, thanks for pointing that out. I tried to create a scenario where clSetProgramSpecializationConstant returns CL_COMPILER_NOT_AVAILABLE, which currently isn’t covered by the CTS. However, you’re right that the program should first be created with clCreateProgramWithIL.
I can’t find an appropriate test that covers the scenario (CL_COMPILER_NOT_AVAILABLE + clCreateProgramWithIL), so this will probably need to be handled as a separate issue/PR.
|
|
||
| REGISTER_TEST(consistency_missing_compiler) | ||
| { | ||
| cl_bool compilerAvail = true; |
There was a problem hiding this comment.
Nitpick - same type of code occurs in a few other places, also:
| cl_bool compilerAvail = true; | |
| cl_bool compilerAvail = CL_TRUE; |
| if (linkerAvail || !compilerAvail) | ||
| { | ||
| log_info("Can't perform linker consistency check\n"); | ||
| return TEST_SKIPPED_ITSELF; |
There was a problem hiding this comment.
This should be an error. Both the full profile and the embedded profile say for CL_DEVICE_LINKER_AVAILABLE:
This must be CL_TRUE if CL_DEVICE_COMPILER_AVAILABLE is CL_TRUE.
I think it would be fine to skip this test if CL_DEVICE_COMPILER_AVAILABLE is CL_FALSE, though.
There was a problem hiding this comment.
Removed test for CL_DEVICE_COMPILER_AVAILABLE
| size_t line_length = strlen(sample_kernel); | ||
|
|
||
| /* New OpenCL API only has one entry point, so go ahead and just try it */ | ||
| clProgramWrapper program = clCreateProgramWithSource( | ||
| context, 1, &sample_kernel, &line_length, &err); |
There was a problem hiding this comment.
Nitpicks:
- This seems like a weird and confusing (and copy-pasted) comment. Can we just remove it?
- Since
sample_kernelis NUL-terminated, we can just passnullptrforlengths, vs. callingstrlenexplicitly.
This is historical.
This behavior was carried forward into OpenCL 1.2 and beyond, so |
Thanks! |
2 participants
Fixes #955
@kpet @bashbaug I've noticed procedure
clBuildProgramdoes not returnCL_LINKER_NOT_AVAILABLE, onlyCL_COMPILER_NOT_AVAILABLE. Is this intentional ? What if compiler is available but linker isn't ? Should it still returnCL_COMPILER_NOT_AVAILABLE? Thanks