Creating Universal binaries for OpenCL Kernel for Intel GPU

0
votes

We write OpenCL C code and clCreateProgramWithSource and use clGetProgramInfo to get the binary. This binary is then integrated to the product binary which uses clCreateProgramWithBinary when initializing it.

We create a .h file and include the same in the source file. The content of the .h file is the binary generated after compiling OpenCL C Kernel.

The issue with the above step is, the compatibility of the binary is expected to break with any minor/major change in OpenCL and it will most likely break across vendors. We need to generate the OpenCL Kernel binary for each vendor or OpenCL release.

It is possible to integrate the OpenCL Kernel binary in header form to the project. In this case, if the binary is incompatible, we will not be in position to replace the binary. In such cases, the project initialization fails.

Expected Solution

The OpenCL C source is proprietary to the company and cannot be shared with the customers.

  • Since the OpenCL Kernel binary is integrated with the project library, we need to understand if it is possible to generate binary which can re-organize itself while clCreateProgramWithBinary to fit to the target platform.
  • If it is absolutely necessary to generate the binary once for each vendor/OpenCL minor/major revision and store it to disk (which will be done at end user’s machine), how can we protect the source which proprietary to the company (is SPIR the only option)?

I already visited Universal binaries for OpenCL but it suggests that SPIR also takes long time in compilation and hence it might not be the solution I am looking for since the init time is also important.

1
binaryopencl

1 Answers

0
votes

In practice the Intel Gen binary format can change on driver changes for the same platform/hardware (e.g. for bug fix workarounds and performance improvements). Hence, the bits returned by clGetProgramInfo are only sure to work in clCreateProgramWithBinary on the same device x driver x etc... Sadly, this means that the binary path is a poor match for the intellectual property security problem.

SPIR sort of splits the difference as it would be hardware independent while still being harder to reverse engineer. If startup performance is somehow important, you can always try the clCreateProgramWithBinary path; just be able to fall back to SPIR should the binary load fail (meaning the driver changed or something).