Debbuger lines offset

Debbuger lines offset

Imagen de dpshamonin
dpshamonin
Mar, 24/04/2012 - 03:57

Hi,

I've been working for quite a while with 1.5 x64 SDK version since it was released.
Just today I've updated to the latest 2012 x64 SDK.

Details:
What I've noticed is that sometimes while Debbuging you OpenCL code (*.cl)
the position of the current execution line does not corresponds with actual line in the file.

Take a look at my example screenshot. I've placed debug break point at the begin of the kernel.
So, debugger stopped at that break point, but actually it is not there. Only after stepping over 7 lines
variable uint gi = get_global_id(0) will be initialized.
The OpenCLJIT says: OpenCLJIT!BSplineDecompositionImageFilter() Line:173
but actually line uint gi = get_global_id(0); located on 166

Also if the OpenCL function is very simple like this:

float compute(const float index,
__global const INPIXELTYPE* in)
{
return 0.0;
}

You will not be able to put exact breakpoint inside. So, what I have to do is to put
more breakpoints below this function hoping some of them will be triggered.
That is crazy way of working.

I' don't know what is the cause of this problem. I've tried to experiment with Linux/Windows file formats,
tabs vs spaces, removing comments, making all parameters of the functions in one line
float compute(const float index, __global const INPIXELTYPE* in)

No effect. Also for some *cl files all the sudden it is working properly.
Also I can just close my solution and open one of the Intel's examples and it is perfectly fine.

I was hoping that 2012 SDK will solve it, but not :/
This problem still exist both for VisualStudio 9 and 10 in 2012 SDK and 1.5 SDK.

Do you have any ideas what could trigger this behaviour in Intel OpenCL debbuger?
I've attached screenshot from VisualStudio 10

Thanks, Denis

RSS Superior
publicaciones de 3 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Yuri Kulakov (Intel)
Yuri Kulakov (Intel)
Mar, 24/04/2012 - 04:34

Hi Denis,

I have
noticed similar behavior on some of the NVidia samples that preprocess the
kernel file to add some "header" text to it. So clCreateProgramWithSource
uses modified file while the original is displayed to the user in MS VS.

Could you please check that you pass the same (unmodified) file to clCreateProgramWithSource?

Thanks,
Yuri

Superior
Imagen de dpshamonin
dpshamonin
Mar, 24/04/2012 - 05:53

Hi Yuri,

AH! Indead! I am using modified version of the oclUtils.h from NVIDIA

//////////////////////////////////////////////////////////////////////////////
//! Loads a Program file and prepends the cPreamble to the code.
//!
//! @return the source string if succeeded, 0 otherwise
//! @param cFilename program filename
//! @param cPreamble code that is prepended to the loaded file, typically a set of #defines or a header
//! @param szFinalLength returned length of the code string
//////////////////////////////////////////////////////////////////////////////
extern "C" char* oclLoadProgSource(const char* cFilename, const char* cPreamble, size_t* szFinalLength);

In this implementation you are able to prepend cPreamble to the begin of the file, in my case that is:
#define DIM_1
#define BUFFSIZE 4084
#define BUFFPIXELTYPE float
#define INPIXELTYPE short
#define OUTPIXELTYPE float

Thats why I am keep getting this offset! Oh! Did not realize it till you reply :)
Maybe that is good idea to add NOTE somewhere on
http://software.intel.com/en-us/articles/debugging-opencl-kernels-using-...

That if you are planing to use debugging, make sure that you have not changed you original code located on disk by adding extra #defines or functions created on the fly, otherwise you will get this type of problem :)

Thanks!
Denis

Superior

Inicie sesión para dejar un comentario.