OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU
Announcements
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.
1663 Discussions

Create kernels from pre-compiled .ir

Mike_B_4
Beginner
183 Views

Hello,

I have a question regarding the creation of kernels from pre-compiled .ir files.

I create a .ir using ioc32 –cmd=compile –input=kernel.cll –device=GPU –ir=kernel.or

In my code I:
a) Load the .ir from file
b) Create a clProgram clCreateProgramWithBinary with my binary (clBuildProgram(my cl_program 1, &my_cldevice, NULL, NULL, NULL))
c) Call clBuildProgram with the clProgram created from above.
 
b) and c) complete with no error 
 
However when I call clCreateKernel a CL_INVALID_KERNEL_NAME error is returned.
 
Should I expect the above to work? (If I use -cmd=build in my command line clCreateKernel cimpletes with no error. But it seems redundant to call clBuildProgram on a pre-built executable ,ir
 
I am using version 1.5.0.43 on a Broadwell device
0 Kudos
3 Replies
Robert_I_Intel
Employee
183 Views

Hello Mike,

Yes, you need to do -cmd=build. Looks redundant, but that is the way it is specified in the standard. If you use -cmd=compile, that is the equivalent of calling clCompileProgram, which should be followed by clLinkProgram. 

For more details, you can check my article on using binaries of different sorts: https://software.intel.com/en-us/articles/using-spir-for-fun-and-profit-with-intel-opencl-code-builder 

Mike_B_4
Beginner
183 Views

Thank-you for the clarification Robert.

I have a related question. If I build a .ir binary using ioc32 -cmd-build will this work for multiple platforms or is a separate build need to be performed on aper platform basis

 

 

 

Robert_I_Intel
Employee
183 Views

Native binaries are not generally portable between generations of the graphics architecture. If you are targeting 3rd gen (Ivy Bridge), 4th gen (Haswell) and 5th gen (Broadwell) chips, you should build native binaries on those platforms. I asked our compiler team to enable building binaries for different architectures using a single machine, and they are working on this, but it will take some time. In general, I would advise not to distribute native binaries to the end users. It is better to either distribute source, possibly in encrypted fashion, build it into binary on the first invocation of the program, and then continue with that binary (if the user updates the driver, you are safer if you discard the hashed binary and rebuild your program) or use SPIR binary, where available.

Reply