1

We have an OpenCL program that works fine on my OS X machine. We just set up a machine with a Xeon Phi and Intel MPSS. However, even when not using the Phi but the Xeon CPU, the CL_PROGRAM_BUILD_STATUS we get is CL_BUILD_NONE.

Unfortunately, we cannot find any documentation on what might cause CL_BUILD_NONE. Do you have any suggestion on how to debug this?

Thank you in advance!

Versions:

[@memphis:~] $ cat /etc/SuSE-release 
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2

[@memphis:~] $ uname -a
Linux memphis 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) x86_64 x86_64 x86_64 GNU/Linux

[@memphis:~] 1 $ rpm -qa |grep intel
intel-mic-2.1.6720-15.suse
intel-mic-mpm-2.1.6720-15.suse
opencl-1.2-intel-mic-3.0.67279-1
intel-mic-sysmgmt-2.1.6720-15.suse
intel-mic-kmod-2.1.6720-15.3.0.13.0.suse
intel-mic-gdb-2.1.6720-15.suse
intel-mic-flash-2.1.386-3.suse
intel-mic-cdt-2.1.6720-15.suse
opencl-1.2-intel-devel-3.0.67279-1
intel-mic-micmgmt-2.1.6720-15.3.0.13.0.suse
opencl-1.2-intel-cpu-3.0.67279-1
intel-mic-gpl-2.1.6720-15.suse
intel-mic-crashmgr-2.1.6720-15.suse
mrks
  • 8,033
  • 1
  • 33
  • 62

2 Answers2

1

The documentation for clGetProgramBuildInfo seems pretty straightforward:

CL_BUILD_NONE. The build status returned if no clBuildProgram, clCompileProgram or clLinkProgram has been performed on the specified program object for device.

You mention that your program worked on other platforms, but maybe you ended up with a slightly different flow between platforms which led to those methods not being properly invoked in the new flow? I'd suggest carefully verifying the return value from the earlier invoked functions to see you get what you expect to get.

Oak
  • 26,231
  • 8
  • 93
  • 152
  • Thank you - that was a good suggestion. Turns out it was a programming error on my side and a different interpretation of clBuildProgram between Apple and Intel (see my other answer). – mrks Jul 21 '13 at 12:03
1

Found it. I am not sure why I had &ret (cl_int return value) as the last parameter instead of having it as the return value of clBuildProgram. Moving it and setting the last parameter to NULL fixes the problem:

wrong:
clBuildProgram(*program, 1, &device_id, opts.str().c_str(), NULL, &ret);
correct:
ret = clBuildProgram(*program, 1, &device_id, opts.str().c_str(), NULL, NULL);

I do understand why this problem occured - apparently the compiler / the OpenCL libraries understood that I wanted to use pfn_notify and asynchronously build my kernel. I am, however, not sure if this behavior is fully conformant to the OpenCL documentation:

If pfn_notify is NULL, clBuildProgram does not return until the build has completed.

In my code, the pfn_notify argument was actually NULL, however user_data was (erroneously) not. While my code didn't make any sense, I believe that user_data should be ignored when pfn_notify is NULL.

I posted this on the Intel forums to see if they agree with my interpretation of the documentation.

mrks
  • 8,033
  • 1
  • 33
  • 62