topic Native binaries are not in OpenCL* for CPU

Create kernels from pre-compiled .ir

Mike_B_4 — Wed, 01 Apr 2015 13:18:52 GMT

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

Hello Mike,

Robert_I_Intel — Wed, 01 Apr 2015 16:29:36 GMT

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

Thank-you for the

Mike_B_4 — Wed, 01 Apr 2015 16:55:02 GMT

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

Native binaries are not

Robert_I_Intel — Wed, 01 Apr 2015 17:06:26 GMT

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.