Archives Discussions

[stenr]

Hi,

I am a newbie on codexl, but I think I have got it to work. Looks promising. My only problem so far, seems related to hitting breakpoints in my .cl files. This means I can successfully add breakpoints at cl-functions, such as clEnqueueNDRangeKernel, using the breakpoints view. Then I can step into my kernel code using F11. I would like to be able to add breakpoints in my .cl code, in order to avoid stepping through for-loops in the kernel code. If I shift+F11 inside a for-loop in the .cl file, I come "on the other side" of the clEnqueueNDRangeKernel breakpoint. Should I add some project settings somewhere, or are there any limitations on the .cl-files or how they are built, in order to get them working in codeXL? The .cl files are added to the VS project.

Btw. .cl breakpoints work in the teapot sample.

I use CodeXL 1.3, OpenCL 1.2, VS2012 and AMD FirePro W7000.

Best Regards,

StenR

[urishomroni]

Hi StenR,

CodeXL is supposed to identify the .cl files from the solution, if the source code passed to clCreateProgramWithSource is exactly the same.

However, some situations (passing the string through a utility class that normalizes line endings, concatenating several strings, using sprintf to change the source, etc.) can cause the string passed to clCreateProgramWithSource to vary a little bit.

You were on the right track, but didn't quite get there, here's what you should do:

1. Set a breakpoint on the kernel function name, or set a breakpoint on clEnqueueNDRangeKernel and use F11 to go into kernel debugging.

2. Once the kernel is dispatched, CodeXL will open a Visual Studio source window for the kernel source. It will either be the file from your solution or a temporary file (named <application name>-OpenCLContextX-CLProgramYYY.cl) if the match was not exact.

3a. If the file is the file from your solution, you should be able to just set breakpoints in it and run to them (with F5), and these will persist to the next run of the application.

3b. If the file is a temporary file, you can set a breakpoint in it - but the next time you run the app a new temporary file might be generated, so the breakpoint might no longer work, and you'll have to repeat steps 1-2.

4. Either way, since the for loop is not considered a function (i.e. it does not add a level to the call stack) - pressing F11 will not run to its end, but rather exit the kernel. Set a breakpoint on the first line of executable code after the for loop to reach it.

Hope this helps,

[stenr]

Thanks for your suggestions! Now I am able to also break on the kernel-function, again by adding breakpoints using the breakpoints view. The source file that shows up is the correct .cl file (no temporary). One peculiar thing I noted is that when it breaks, it jumps to the first line in the file, but when pressing F10/F11 it moves to the correct kernel function. 

But the problem of not being able to set breakpoints persists. After breaking on the kernel function and setting a breakpoint (as in 1+2+3a above), it does not break.when hitting F5. 

I had the problem of VS2012 crashing (so I disabled automatic indentation as suggested in this forum). Can this somehow be related?

Regards,

StenR

[urishomroni]

The smart tabs issue is unrelated to the breakpoint or kernel debugging in specific and is just a bug with the VS code editor that CodeXL is triggering.

As for the source breakpoints, this is an issue of which we are not currently aware.

If you could supply us with the kernel source (and details on which kernel you are trying to debug as well as on what line are you specifying the source breakpoint), we could try reproducing the issue in our labs.

In the meantime, a few other questions just to try and fathom what's up:

1. If you set a breakpoint on an executable line before the for loop and continue (F5) to it - is the breakpoint hit?

2. Same question, only with the breakpoint inside the for loop.

3. Is there a way for you to shorten the for loop to a lower number of iterations and seeing if you are able to step / hit breakpoints out its other side then?

4. If you try debugging your application in the standalone CodeXL app, are you seeing the same issues? anything behaving differently? (be sure to set the kernel source code folder in the project settings to find the .cl files where they are loaded).

Thanks,

[stenr]

Hi,

I simplified the file to do almost nothing and have verified that the problem is still there (see code below). In this file, the behavior is independent on where I set the breakpoint. I have now verified that breaking actually works in a few of my other .cl files in the same project, so there seems to be something with this particular file and how it is being built. I think I will continue to dig a bit myself and report back if I discover something.

To take your questions in order:

1+2+3) No, breakpoints set by mouse clicking anywhere in the file, break. Only points set by breakpoints view.

4. I struggle a bit here. I manage to start our application and initialize it, but then it crashes with "Program error. unable to locate binary". No other details in the message. Not sure how to debug. (The application runs fine when starting it directly from windows (no need to start from VS)). Based on the timing of the crash, it might well have something to do with opencl. But I do not know...

Best regards,

Sten Roar Snare

kernel void MyKernel (read_only image2d_t  pts, read_only image2d_t  input,

                        write_only image2d_t output)

{

    int2 pos;

    pos.x = get_global_id(0);

    pos.y = get_global_id(1);

  int2 pts_dim = get_image_dim( pts );

    int2 dim     = get_image_dim( input );

    // bounds checking

    if ( (pos.x >= pts_dim.x) || (pos.y >= pts_dim.y) )

        return;

    // do something

    float2 mDir = (float2) (pos.x, pos.y);

  write_imagef(output, (int2)(pos.x, pos.y), (float4)(mDir.x, mDir.y, 0.0f, 0.0f));

}

[stenr]

Found the problem. We use some -D statements in the build options, in order to let the user change some parameters (such as window sizes) in the program. When the user changes parameters and, in our implementation, during setup, a new build of the opencl code is triggered and causes codexl breakpoints to stop working. I guess we should reconsider our design or work around it for debugging purposes.

Regards,

Sten Roar Snare

[urishomroni]

Hi Sten,

Sorry for the long time in replying.

We have finally managed to reproduce the issue in our labs.

We are currently looking into its cause and seeing if we can fix it or find a workaround.

Thanks for the detailed report!