clGetProgramBuildInfo returns CL_BUILD_NONE

clGetProgramBuildInfo returns CL_BUILD_NONE

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

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Markus,

What happens if you perform the following command:
ioc64 -cmd=build -input=any_opencl_kernel.cl

Thanks,
Yuri

Hi Yuri,

thanks for the tip - I wasn't aware of that. However, ioc64 seems to build the kernel fine:

[@memphis:~/logreg] 1 $ ioc64 -cmd=build -input=reduce.cl 
Setting target instruction set architecture to: Default
Intel OpenCL CPU device was found!
Device name:        Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
Device version: OpenCL 1.2 (Build 67279)
Device vendor: Intel(R) Corporation
Device profile: FULL_PROFILE
Compilation started
Compilation done
Linking started
Linking done
Kernel <reduce> was successfully vectorized
Done.
Build succeeded!

I build the kernel using the following commands:

*program = clCreateProgramWithSource(context, 1, (const char **) &cSourceCL, &program_length, &ret);
clBuildProgram(*program, 0, NULL, opts.str().c_str(), NULL, &ret);

Leaving out the opts doesn't change anything. I also added a syntax error to the CL code - it doesn't get parsed. If there is any more information I can give you to help, let me know. I didn't want to paste my whole source code here. ;)

Also, adding a device list to the clBuildProgram doesn't help.

Thank you for your help!

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.

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.

Glad the issue is solved.

Your assumptions regarding pfn_notify == NULL, user_data != NULL case look reasonable. I will submit a ticket after reproducing.

Thanks,
Yuri

Hi, do you test your kernel now?

JudLup Luna

Could you rephrase your question, please? The kernel works now, if that is what you mean.

Leave a Comment

Please sign in to add a comment. Not a member? Join today