Wrong number of kernels returned

Accelerated Computing CUDA CUDA Programming and Performance
1

Hi,

my configuration is a GTX 285 under Vista x64, 258.96 drivers. I’m using the official OpenCL C++ wrapper to dynamically (re-)create a program for a given context if the kernel source code has changed. The source code basically is:

// Put the whole source code into a single line.

cl::Program::Sources lines(1,std::make_pair(m_source_code.c_str(),m_source_code.length()));

// (Re-)create and build the program.

delete m_program;

m_program=new cl::Program(*m_context,lines,&result);

if (result==CL_SUCCESS) {

	// Get all devices in the context.

	DeviceList devices=m_context->getInfo<CL_CONTEXT_DEVICES>();

	result=m_program->build(devices);

	if (result==CL_SUCCESS) {

		VECTOR_CLASS<cl::Kernel> kernels;

		result=m_program->createKernels(&kernels);

		assert(result==CL_SUCCESS);

	}

}

The code works fine if executed for the first time, but afterwards the assert fails with result==CL_INVALID_VALUE. When debugging into createKernels(), it turns out that the first call to clCreateKernelsInProgram() succeeds and results in numKernels==0 (which already is wrong, I checked that the source code is not empty and compiles fine), but the second call to clCreateKernelsInProgram() returns CL_INVALID_VALUE. According to the documentation, CL_INVALID_VALUE is only returned “if kernels is not NULL and num_kernels is less than the number of kernels in program”. So if the number of kernels really was 0 as returned by the first call, the second call should not fail, which leads me to believe there is a bug in the frist call to clCreateKernelsInProgram().

Any hints for a work-around?

Thanks.

2

As it turns out, the source code was empty due to a bug, so the reported number of kernels of 0 was correct. However, as alloca() used by createKernels() “allocates a zero-length item and returns a valid pointer to that item [if size is 0]”, kernels is not NULL and num_kernels is not less than the number of kernels in program, so wasn’t expecting clCreateKernelsInProgram() to fail. Still, I’m somewhat glad it did, as it has helped me to track down the problem.

3

As it turns out, the source code was empty due to a bug, so the reported number of kernels of 0 was correct. However, as alloca() used by createKernels() “allocates a zero-length item and returns a valid pointer to that item [if size is 0]”, kernels is not NULL and num_kernels is not less than the number of kernels in program, so wasn’t expecting clCreateKernelsInProgram() to fail. Still, I’m somewhat glad it did, as it has helped me to track down the problem.