Number of issues on Intel OpenCL 1.5 (x64)

[dpshamonin]

Hi,

I've create the simple application(attached) to test the OpenCL implementation across different parties.
Currently playing with Intel and Nvidia, ATI next in the list. You would need CMake to build it.

Very happy that Intel provides very nice OpenCL framework. 
But, here is something that I've noticed based on this simple example and Intel OpenCL 1.5.

1. The application may crash at the moment clEnqueueReadBuffer is calles: 
ciErrNum = clEnqueueReadBuffer(cqCommandQueue, cmOUT, CL_TRUE, 0, mem_size_OUT, O, 0, NULL, NULL);

It will crash in _threadstartx[xxxx] not in MainThread. The output is:
...
'oclsimple3d.exe': Loaded 'C:\\Program Files (x86)\\Intel\\OpenCL SDK\\1.5\\bin\\x64\\clbltfnh8.dll'
'oclsimple3d.exe': Loaded 'C:\\Program Files (x86)\\Intel\\OpenCL SDK\\1.5\\bin\\x64\\__ocl_svml_h8.dll'
HEAP[oclsimple3d.exe]: Heap block at 00000000142EEB20 modified at 00000000142EEF88 past requested size of 458
Windows has triggered a breakpoint in oclsimple3d.exe.
This may be due to a corruption of the heap, which indicates a bug in oclsimple3d.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while oclsimple3d.exe has focus.
The output window may have more diagnostic information.

Note1: this will not happen always. At the first run of the program, it could be fine.
Note2: Never happens on Nvidia

2. The icldbgsrv.exe (Intel OpenCL Debugger) may sometimes pop up the cmd console even if you are not in 
Visual Studio. Not sure when and why that happens, 
but you can't see anything on this console window, so close it and that is all.

3. The same application may crash at the moment clReleaseKernel is called.
if(ckKernel)clReleaseKernel(ckKernel); 

Note: this is harder to reproduce, but happens.

4. If in Visual Studio you switch from Debug to Release mode while you still has 'Enable OpenCL kernel Debugin'.
The program will freeze even before clCreateContext... is called. So, you have to disable 'OpenCL kernel Debugin'
then it will run again.

5. Something about Intel OpenCL Debugger. Assume you have simple kernel which calls function foo():
void foo(const __global float* in1, const __global float* in2)
{
}
__kernel void simple_test(const __global float* in1, const __global float* in2, uint2 in_size1, uint2 in_size2)
{
  foo(in1, in2);  // fine
  foo(in1, 0);  // Intel Debbuger will crash in debug mode, but works fine in release!
  foo(0, 0);  // Intel Debbuger will crash in debug mode, but works fine in release!
}

So, Intel OpenCL Debbuger really does not like when null(0) is passed to the function. In this case 
Visual Studio just close in a blink of the eye :/ I've noticed that passing NULL to kernels or 0 to OpenCL functions
is not welcome on Intel OpenCL Debugger.

Note: this test does not present in my example.

For me the issues number 1,3 has high priority, because it is stopping factor.
I really hope you could fix it for the next release. 

Thanks,
-Denis

[Eli_Bendersky__Intel]

Hello Denis,

I will address your debugging-related questions. We're investigating the other issues and will try to provide an answer for those as well, as soon as possible.

(2) and (4) are known problems that we're fixing towards the next release of the SDK.
(5) Thanks for reporting - we'll look into it.

Thanks for your reports