OpenCL Breakpoint in visual studio 2010 does not work

[cheng_z_Intel]

I'm a novice for OpenCL and I'm ramping up Intel SDK for OpenCL following the Intel SDK for OpenCL 2013 Application 2013 User's Guide for Windows OS. I met an problem about OpenCL debug the breakpoint in OpenCL file does not work in Visual Studio 2010

Here is some of the environment information:

OS: Windows 7 Enterprise.

Processor: Intel(R) Core(TM) i7-3770T CPU @ 2.50GHz

Intel SDK for OpenCL Application Kernel Builder version: 3.0.0.1

I followed the steps in the guide document. Enabled opencl kernel debugging and set work items properlly before debugging, added "-g -s" in build parameters and set the breakpoints properlly, then press "F5' to run debug, but the app cannot break at the openCL breakpoints. I tried to use other port in the "Advanced Setting" but it still does not work.

Anyone could help?

[Yuri_K_Intel]

Hi, Below is the list of steps. Could you please try them to check where behavior is different. 1. Make sure that you have only 1 instance of Visual Studio open. 2. Check that OpenCL debugger is enabled in the "Tools->Intel SDK for OpenCL - Debugger" dialog. 3. Check the work-items value in the same dialog with respect to kernel execution. This is important in case the kernel runs with some offset and with the default work-items value (0,0,0) the debugger will not stop at the kernel breakpoint. 4. Make sure that you are working with Intel OpenCL platform and you select CPU device. 5. Add necessary build parameters to clBuildProgram like so: clBuildProgram(g_program, 0, NULL, "-g -s c:\\work\\ToneMapping\\ToneMapping.cl", NULL, NULL); 6. Make sure that the kernel source file you open in Visual Studio is the same file/text you pass to clCreateProgramWithSource function. 7. Put a breakpoint at host code right before (or at) clCreateContext function call. Put another breakpoint at kernel function code. Make sure that you put the breakpoint at the same kernel function that will be called/enqueued later. 8. Run the debugging session (F5). The debugger stops near clCreateContext. At this point the kernel breakpoint should be shown as not active (The breakpoint will not currently be hit...). 9. Step over the clCreateContext function call. At this point the kernel breakpoint should become active, showing something like "At ToneMapping.cl, line 60 in process 'icldbgsrv.exe'". 10. Continue debugging (F5) - kernel breakpoint should be hit. Thanks, Yuri

[cheng_z_Intel]

The problem is solved. The root cause is that I'm passing a relative path but not a full path of the OpenCL file name in clBuildProgram function like below.

clBuildProgram(g_program, 0, NULL, "-g -s c:\\work\\ToneMapping\\ToneMapping.cl", NULL, NULL);

Is this an existing issue or expected behavior do you think?

Thanks

Cheng

[Yuri_K_Intel]

Glad to hear it works now. Regarding full path - yes, I think this is by design. Thanks, Yuri

[Ibtsam_H_]

Its not working for me. I have followed the steps that you have mentioned, and I can even see the breakpoint becoming active and saying "At myKernel.cl, line 222 in process 'icldbgsrv.exe'", but still the breakpoint does not get hit. I am using Intel OpenCL 2.0 platform, and the device is CPU, Core i5-3317U @ 1.7 GHz.

[Yuri_K_Intel]

Hi Ibtsam, Could you please try to debug a kernel of some Intel sample (for example ToneMapping)? You might try both OpenCL 1.2 and 2.0 platforms. If the kernel debugger will be able to debug a sample, then I'd like to ask for a minimal reproducer (stripped down version of your project) which still exhibits the problem. Thanks, Yuri

[Ibtsam_H_]

Dear Yuri,

I tried putting a breakpoint in the ToneMapping Intel sample, and it is working pretty well. I tried the sample with both OpenCL 1.2 and 2.0 and the breakpoint gets hit successfully. I have done  the same steps to set the breakpoint in my own project but the breakpoint does not get hit. I used OpenCL 2.0 for my project, as it gives a build error when I use OpenCL 1.2.

Now I would try to embed my kernel into the framework and project structure used by the Intel Sample and see if the breakpoint gets hit. If it still does not get hit, I would then provide a minimal reproducer for your scrutiny.

Thanks,

Ibtsam