- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm trying to debug my OpenCL kernel (on CPU) with the debugging utility in VS2010 but I got a OCLSocketError message !
I work in local and have no local firewall !
I have also try to change th IP port... but it is the same ! Anyway I have no firewall so I don't understand why it does not work !
The result is that when I put a break point in my .cl file, the application lock but never go the the .cl file breakpoints !
Any help ?
Thanks
Link Copied
21 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Polar01,
Could you please provide the full error log/printout you're getting in this case?
Thanks
Could you please provide the full error log/printout you're getting in this case?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sure (sorry for the delay),
I have retry, here is what I do :
1 - I generate (on the fly) the kernel source code and save it in kernel.cl
2 - I have add the kernel.cl file in my VS2010 solution
3 - I put a breakpoint in kernel.cl
4 - I restart the application (it will regenerate the same kernel.cl file)
5 - The application run, but does not stop !
In visual studio, the breakpoint is disabled and if I move my mouse over it I got the message :
"The breakpoint will not currently hit. No symbols have been loaded for this document"
I have try to change the TCP port (use a non-default one), it is the same !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So there no longer is an issue with a socket error?
For the debugger to stop on the kernel as expected, you must pass the full path to the file MS Visual Studio knows about to clBuildProgram with the "-p" flag (and of course set "-g" too). Even if you actually generate the file on the fly, the full path passed to clBuildProgram must match the full path of the file you open with Visual Studion and put a breakpoint on.
For the debugger to stop on the kernel as expected, you must pass the full path to the file MS Visual Studio knows about to clBuildProgram with the "-p" flag (and of course set "-g" too). Even if you actually generate the file on the fly, the full path passed to clBuildProgram must match the full path of the file you open with Visual Studion and put a breakpoint on.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks,
It is what I do :
I have try with :
"-g -s c:\kernel.cl"
"-g -p c:\kernel.cl"
But none work ! Visual studio does not stop in my code !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
You should use "-g -s c:\\path\\to\\your\\kernel.cl" as build options string for the
Please, attach a small reproducer if the issue is not resolved.
Thanks,
Yuri
You should use "-g -s c:\\path\\to\\your\\kernel.cl" as build options string for the
clBuildProgram
. Pay attention to double backslashes. You also need to enclose the path by escaped quotes if it contains spaces: "-g -s "c:\\path\\with spaces\\kernel.cl"".Please, attach a small reproducer if the issue is not resolved.
Thanks,
Yuri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks,
But it does not work too !
What I have noticed is that I can't set the breakpoints in the .cl file, except if I put my build options in a static char*, this way :
static char* KERNELPATH = " -g -s "E:\\spectral\\spectralLight\\Kernels_Generated\\kernel__ProductionRenderer.cl"";
Also, I got the following exception :
First-chance exception at 0x000007fefdd6cacd in spectralStudio.exe: Microsoft C++ exception: OclSocketError at memory location 0x0c0efa78.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you please try the following steps. I also suggest to perform them with some simple OpenCL application/sample first.
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks,
I have download the tone-mapping sample and do exactly what you propose. I got the exact same behavior than you described !
So, I do exactly the same with my project !
I have also try to add my kernel code to the tone-mapping kernel, and it works !
What can cause this problem ? I use the C++ interface to create my clContext, Queue etc... just for information !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have an idea of the problem ? Why the sample work but not my application !?
Can it be related to the OpenCL C++ API ? or the way I create my context ?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It definitely cannot be related to C++ interface, it should work fine.
Regarding other possible reasons it's quite hard to say without the code. If you share a small reproducer I will try to look into it.
Regarding other possible reasons it's quite hard to say without the code. If you share a small reproducer I will try to look into it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I understand,
Unfortunately it is difficult because the software is really big... the kernels are generated dynamically etc...
So, doing a small reproducer is difficult...
Also, the samples are working but not my application... something make the difference, but what !!!!
Thx
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you perform steps 1..10 with your application in which step the behaviour becomes different?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have discover something,
In the same .cl file there are 2 kernels, a small one and a big one. I can debug the small one !
But the not the big one !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have found something else.
When I debug the first kernel, then continue ... I enter into the other kernel !
Then I go step by step and it crash after the initialization of the 4th parameter !
What is strange is that without debugging, the kernel work (on both Intel and NVidia).
I have also check for alignement and if both memory buffer are correctly created, I found no problem !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Without a minimal reproducer, it will be very hard for us to help you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I understand, but I have try without success !
Something else, it will be fine if we can put a breakpoint and it stop on any work-item (and not a specific one) !
By example, some case happend is rare cases but I still need to debug them... when happening !
Also, it will be fine that the debugger stop at the right line when a access-violation occur (if no corruption occur of course), when possible !
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I continue to debug and found that I can enter into the kernel, in the method initialization but when I step over the parameter 'pixmapsBuffer' it throw an exception in the output.
Pixmap buffer is declared this way :
Pixmap buffer is declared this way :
typedef struct __attribute__((packed)) { float x, y, z; } RGBMap;
__global __read_only RGBMap* pixmapsBuffer;
Pixmap buffer is allocated this way :
static int NULLBUFF = 0;
_clBuffer_Pixmaps = new CLMemory(*_context, CL_MEM_READ_ONLY | CL_MEM_USE_HOST_PTR, 1, &NULLBUFF);
Notice that the buffer size is 1 (1 byte), simply because I don't use it ! But use a 'RGBMap*', can it be the problem ?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems related because when I put something in the pixmap buffer, it does not stop at this argument.
BTW, the exception is :
But I'm still unable to enter into my kernel (maybe some other buffers have a size=1 too, I have to check).
BTW, the exception is :
First-chance exception at 0x000007fefd6acacd in spectralStudio.exe: Microsoft C++ exception: OclSocketError at memory location 0x0de1fa78..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you think that we can expect more robust (more detailed description) when the OpenCL debugger crash !
Because now, it seems to be hard to find the reason of the problem.
Anyway, I have retest and it seems that if I don't setup some buffer with some valid data... I cannot trace step by step each parameter.
Now, I still have no idea how to enter and debug my main kernel :-(
Can you help please ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Polar01,
As your were previously told, it is very difficult to help you debug without a reproducer. You can try another option.
You mentioned that you were able to debug the sample and not your kernel, right? Can you capture your dynamically generated kernel, plug it into the sample app (replace the .cl file in the sample with your kernel that is causing the problem) and set the appropriate kernel args and see if you are able to debug it. If are running into the crash provide us the sample with your kernel and we will be able to help.
Thanks,
Raghu
As your were previously told, it is very difficult to help you debug without a reproducer. You can try another option.
You mentioned that you were able to debug the sample and not your kernel, right? Can you capture your dynamically generated kernel, plug it into the sample app (replace the .cl file in the sample with your kernel that is causing the problem) and set the appropriate kernel args and see if you are able to debug it. If are running into the crash provide us the sample with your kernel and we will be able to help.
Thanks,
Raghu
![](/skins/images/B7BA37F9CE4B52FF7CAE1FB0388839C8/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page