When opencl 1.1 drivers will be available (I mean the final driver, not a beta) ?
Is there any OpenCL debugger ? I’ve tested NSight and it works fine for CUDA, but it seems to be unable to debug opencl program. Am I correct ?
Does somebody know Graphic Remedy ? I’ve heard that they have developped a graphic debugger which handles OpenCL code. But when reaching this page (http://www.gremedy.com/purchase.php), I wonder if they have not gone bankrupt… Is it the case ?
When opencl 1.1 drivers will be available (I mean the final driver, not a beta) ?
Is there any OpenCL debugger ? I’ve tested NSight and it works fine for CUDA, but it seems to be unable to debug opencl program. Am I correct ?
Does somebody know Graphic Remedy ? I’ve heard that they have developped a graphic debugger which handles OpenCL code. But when reaching this page (http://www.gremedy.com/purchase.php), I wonder if they have not gone bankrupt… Is it the case ?
The professional version of NSight is able to debug / profile OpenCL programs, see the feature lists below the screenshots here.
gDEBugger CL has been in closed beta for a while. In fact, the last license key that was sent to beta testers expired Oct 31, 2010, AFAIR. Since then, I’ve not heard anything from Graphics Remedy. In conjunction with the purchase page currently saying “Sorry, we are now reviewing our pricing model. Please come back in a few days.” one might think they are about to get acquired. I doubt them to be bankrupt as I believe their products are well established on the market.
As for another OpenCL debugger / profiler, check out NVIDIA’s Compute Visual Profiler from the CUDA SDK, it can profile OpenCL applications, too.
The “/” in my “debug / profile” sentence was meant to be read as “and / or”, as I was not looking to closely whether both debugging and profiling was possible. Indeed, it seems only profiling, not debugging, is possible currently.
Hi, gdebugguer could not debug OpenCL kernels… Where you see that ? i have try all the beta and it was impossible for us to debug kernels because it misses some API from NVIDIA
However, it’s a great tools to see the memory instead to make EnqueueReadBuffer to debug
I was just relying on the statements on their product page. After all, it depends on what you call “debugging”. I don’t know if you can set breakpoints and inspect variables, but “edit and continue OpenCL kernels” should be possible. I have not checked that, though.
Debugging = put some breakpoints in the kernel …
And gDebuggerCL is not able to make that for the moment
You can update your kernels during the launch but impossible to put some breakpoints in it. However it’s very powerful to see the state of the gpu memory before and after an kernel.
The only solution to see something in your kernel and to put some printf in it and run it with AMD drivers
It seems as far as debugging goes the CPU is the easiest to use. Also AMD supports debugging far better than NVIDIA, so NVIDIA need to add OpenCL to Nsight and something like cuda-gdb for linux.
I have been using the AMD CPU platform on Linux for my OpenCL debugging so far and it works very well. Plus the printf statements are awesome, if NVIDIA add printf then it should become an official Khronos extension (as AMD and Intel already have it).
I am going to give gDebugger a go now that it is free!
With AMD stream SDK on CPU it is impossible to put some breakpoints in a kernel, you can just put some printf(“”)
With the alpha Driver on intel it is the samething you could not debug inside a kernel, but there is a amazing stuff in this alpha driver it is the Intel OpenCL offline Compiler which says if it could arrive to automatically vectorized the kernel, the perf are really amazing as soon as all the kernels are vectorized “compliant” (perf *12 with 4 cores and Hyperthreading activated). Moreover, my examples are always more fast with alpha Intel driver that with AMD Stream 2.2 driver on SDK even with kernel that it is not possible to vectorized.
You can then set breakpoints on any line on your CL file. GDB is very powerful so it should be more than enough for the purpose of debugging a Kernel.
It might be possible to get gdb to work on Windows? After all the Stream SDK uses a Windows port of GNU as and ld.
You could use common general purpose debuggers such as IDB or OllyDbg too. Just wait for the OCLXXXX.dll file to load then set your break points.
The final option would be to intercept the Stream SDK call to GNU as, edit the temporary OCLXXXX.tmp.s file and add some breakpoints, then let as assemble it and hopefully Visual Studio will detect the breakpoint…