cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

soylentgraham
Adept II

How do I supply build arguments(Include path) to opencl program in codexl?

I have an opencl program (which compiles and runs fine in my app), which I want to debug. When I run clBuildProgram I supply some arguments;

-I "data/"

As I'm using a couple of common include files.
When I break[point] into codexl to debug the program it gives me a CL_BUILD_PROGRAM_FAILURE error as I haven't supplied the arguments (and so it doesn't compile)

But I can't find anywhere to put my arguments in!

On a side note though, when I break and look in CodeXL Explorer and select my "OpenCL Program 1", inside the properties it shows the "Program Build Options" WITH the arguments which were supplied at runtime... so... ARE the arguments reaching the program? and it's not compiling for a different reason?

In the properties, "Program build log" is empty, which doesn't help...

0 Likes
8 Replies
dorono
Staff

Hi,

The same call to clBuildProgram that you've used in your application should work when you run your app under CodeXL.

Specifying build options as a string which is clBuildProgram's 4th argument. For an example see the CodeXL sample application "Teapot":

1. To load Teapot, from the menu bar select Help -> Load the Teapot Sample.

2. Set a breakpoint on the clBuildProgram API.

3. Start a debug session.

4. CodeXL will run Teapot and break. The Source Code window will display the source code that makes a call to clBuildProgram.

5. Take a look at the Function Call History view and select the last API call in the list which is a call to clBuildProgram. You will see the arguments in the Properties view:

Arguments

(0x5C8318 - Program 1, 1, 0x17B604, "-D GRID_NUM_CELLS_X=64 -D GRID_NUM_CELLS_Y=64 -D GRID_NUM_CELLS_Z=64 -D GRID_INV_SPACING=1.000000f -D GRID_SPACING=1.000000f -D GRID_SHIFT_X=6 -D GRID_SHIFT_Y=6 -D GRID_SHIFT_Z=6 -D GRID_STRIDE_Y=64 -D GRID_STRIDE_SHIFT_Y=6 -D GRID_STRIDE_Z=4096 -D GRID_STRIDE_SHIFT_Z=12 -I res", 0x000000, 0x000000)

As you can see, the 4th argument is a string containing the build options. towards the end of the string you can see "-I res" specifying the include path to the compiler.

Hope this helps,

0 Likes

I'm already supplying build options in the code, that's not a problem, I THOUGHT I was missing the arguments when [I thought] codexl "built" the program, but now I don't think that's the case (as properties are showing arguments from code), I believe codexl automatically re-builds the program exactly in the same way I as do...

When my app builds the programs (which compile and run fine in MY app), codexl pops up with this error

"Could not build OpenCL program 1 (Context1) for debugging.
OpenCL kernel debugging will be disabled for this pgoram.

Error Code: CL_BUILD_PROGRAM_FAILURE"

(with an empty build log in the properties window)

If I place a breakpoint in my opencl code, an error box pops up;

"The kernel is not debuggable (it was probably built without debugging flags).

Please create the program with clCreateProgramWithSource and build it with clBuildProgram"

Now, I DO create it with clCreateProgramWithSource and I DO build with clBuildProgram. And as far as I'm aware, openCL has no explicit debugging flags? so I'm not sure what that's referring to...

Is there something else in codexl I can look at (logs?) for why I might be getting this error? (I'm using the visual studio plugin)

0 Likes

Hi,

CodeXL, as part of preparing the eventuality that the user might want to perform kernel debugging, adds a few build flags that will enable kernel debugging, such as disabling optimizations and adding debug information.

However, if this fails, CodeXL then tries to build the program with the original build options, to allow program flow to continue. It is fairly rare for a kernel not to allow compiling for debug.

In your case, it seems like the kernel is indeed failing to build for debug. However:

1. The error should not appear in the CodeXL GUI.

2. The message being shown is phrased like it is, since the common case of it happening is people using clCreateProgramWithBinaries.

I will pass the issues on to our bug tracking system. In addition, I will add a feature request to have an option to disable the kernel debugging preparations, for scenarios where they might be obstructive.

If you could supply us with a sample application that reproduces the issue - or at least the kernel source (and relevant include files) to help with the reproduction and testing of the issue, it would be a great help.

In addition, any information on the hardware / device you are targeting with the kernel (Which GPU? is the program also built for the GPU device?) would also be useful.

Thanks,

I'll try and write a small app to reproduce the problem, but this won't be for at least a week and a half. In the mean time I've attached the .cl files... I've built for GPU, CPU and ALL (all have the same issues)

Devices listed in the program property window;

GPU: Redwood  

CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz  

The GPU itself is an ATI Radeon HD 5670 (driver version 8.961.0.0)

The CPU is a pair of dual-core, hyperthreaded xeons, so I have 16 CPU's in windows.

CodeXL version (in help/about): 1.1.2885.0

Using visual studio 2010 (10.0.30319.1)

I've attached BlobPair.cl and EstimatedPerson.cl (these have the kernels and both use the common includes), they both give the same error (I believe because of the cltypes.cl file)

As of now, all the kernels execute fine and work perfectly in my app, I just can't debug them

0 Likes
soylentgraham
Adept II

I tried to see if I could compile the code in a slightly different enviroment, so I loaded my code in the AMD KernelAnalyzer2...

This revealed a couple of things;

a) The kernel analyzer doesn't know what a float3 is (I'm using them extensively for my 2D->3D->2D conversion code). I've switched all my code to float4's (garbage in w) and my previously not-working code is now behaving as expected (my data buffer -one of my arguments- was an array of float3's... now they're float4's things are calculating correctly)

b) the kernel analzyer has no-information when it tries to use #include's...


========== Build: started ==========


OpenCL Compile Error: clBuildProgram failed (CL_BUILD_PROGRAM_FAILURE).


--------


OpenCL Compile Error: Compiling for device: ATI RV710


Internal error: clc compiler invocation failed.


--------


OpenCL Compile Error: Compiling for device: ATI RV730


Internal error: clc compiler invocation failed.


When I open my .cl files I'm including though, I get the same non-descript errors...

So, I'm ASSUMING, when the code is "built" for debugging, it's using something similar to the KernelAnalyzer, which doesn't like my code...

Just for clarity, my "basic types" cl file is the following, and gives no information in the kernel analyzer as to why it doesn't compile... (Works fine in real-world-application)


typedef struct


{


  float2 mStart;


  float2 mEnd;




} clLine2;




typedef struct


{


  clLine2 mLine;


  float mRadius;


  float mDummyAlign;




} clCapsule2;




typedef struct


{


  float2 mPos;


  float2 mSize;




} clRect;




#define MTX_F4


typedef struct


{


  // gr: naming from ofMatrix4x4


#if defined(MTX_F4)


  float4 _mat[4];


#else


  float m0x;


  float m0y;


  float m0z;


  float m0w;


  float m1x;


  float m1y;


  float m1z;


  float m1w;


  float m2x;


  float m2y;


  float m2z;


  float m2w;


  float m3x;


  float m3y;


  float m3z;


  float m3w;


#endif



} clMatrix4x4;








typedef struct


{


  clMatrix4x4 mModelViewProjection;


  //clRect mViewport; // not needed but coupled with the projection matrix




} clCameraParams;




typedef struct


{


  clCameraParams mCameraParams;


  int mDistortEstimatedPersons;


  int mStraightenEstimatedPersons;


  float2 mPersonWorldSize;




} clPersonEstimateParams;


soylentgraham
Adept II

New version of CodeXL: 1.2.3897.0:

- still fails to build kernels when debugging

- kernelanalyzer2 still fails to compile...

Updated drivers (new version of catalyst control center); CCC v13.4..

- still fails to build kernels when debugging

- kernelanalyzer2 WORKS and compiles my programs with no errors!

0 Likes

I also found CodeXL does not like include files.  I had to inline them.

0 Likes

I took this thread way off topic. With codexl 1.2 I had no problems at all with includes; although I don't specify -I<path>, it finds relative includes automatically now

0 Likes