OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU.
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.
1720 Discussions

Suggestion: visual debugger

New Contributor I
Please, develop a visual stand-alone debugger for your OpenCL implementation.

Something like NVIDIA's nSight, but don't integrate into Visual Studio... it's better an OS-portable standalone app ( made in Qt or similar ) so we can use in linux, MacOSX, etc... with minimal effort.

I'm specifically interestered in placing breakpoints and inspecting variables.
Other things I use ( but less times ) are "run to cursor" ( skipping the execution of several lines ahead/backwards ) as well as variable-modify-value ( alter the variable's value manually at runtime ).

You could also add a command line one for the command-line lovers although I would really prefer a visual one.

0 Kudos
2 Replies


Thanks for the advice. Indeed looks like a needed tool. We will explore this.

As a person that also prefer a visual debugger, I would like to express that I usually do use Visual Studio.

So, in the majority of time, it will be unnatural for me to jump out of my C/C++ debugging environment to an OpenCL debug environment.

I prefer to debug my entire application (C/C++ code and OpenCL kernels) in the same IDE.

0 Kudos
New Contributor I
Well, as you mention, to debug C++ and OpenCL in the same IDE ( VS in your case ) would be the more natural.. but if you need to write a debugger plugin for VS2008, other for VS2010, other for Netbeans, other for Eclipse, other for XCode, etc... could be too much work for you.

On the other hand, if you develop a multiplatform app like is my case, you need to learn how to use the debugger for VS, Netbeans, XCode, Eclipse, etc... the debugger could be very similar, but there will be always differences between all the versions ( for instance, its preferences will be located in the VS's menu XXXX while it could be placed in the menu YYYYY inside Eclipse... ).

Writting it as an standalone app solves both problems: less work for you + an unified environment exactly equal for all the OSs.
0 Kudos