OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU.
Announcements
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.

2 Bugs in beta

Polar01
Beginner
1,110 Views
Hi,
Even if I have found that the beta is really good, I still have found 2 problems.
1 - The is no "vloadn" support, I have try to use "vload3/vload4" and I got the following message at compile time : "error: no matching function for call to 'vload4'"
2 - I run my application, and sometimes... it crash in the "ocl... .dll" . Really, I don't know why and where !
It simply crash !
How can I help you to debug this crash ?
0 Kudos
9 Replies
Evgeny_F_Intel
Employee
1,110 Views
Hi,
1>
Try to use this code as a reference, please report if you have any issuewhile compiling it.

You may try it throught the Offline compiler too.
[cpp]__kernel void foo(__global float* in, __global float4* out)
{
	size_t tid = get_global_id(0);
	out[tid] = vload4(tid, in);
}[/cpp]

2>
Can you give exact name of the dll?
Could you provide simple sample that reproduce the failure?
0 Kudos
Doron_S_Intel
Employee
1,110 Views
A good way to try and debug crashes is to first of all run the same code with a blank kernel (just add a return statement as the first line of the existing kernel). If the problem disappears, the issue is somewhere in the kernel code.
If you're running multiple kernels, manually calling clFinish after each submission can help track which kernel is the problematic one.
To debug issues in kernel code, you can try running your code in a debugger and instructing the debugger to catch all exceptions (and specifically access violation), and then look at the backtrace. With the help of the offline compiler tool, it's possible you'll be able to trace the problem to a specific offending kernel source line, at which point you can narrow it down to a reproduction and submit it for us to look at.

Thanks,
Doron
0 Kudos
Polar01
Beginner
1,110 Views
Thanks,
The small kernel compile in the offline compiler... but not my kernel !!!
So, I have do some tests... and found a small solution to fix it.
But it is a hack... you should have an error in your SDK.
This version does not compile :
float4 f4 = vload4(0, &vertices[idx0].P);
BUT ... this version compile :
__global float* fp = &vertices[idx0].P;
float4 f4 = vload4(0, fp);
Can you confirm that it is a bug in the SDK please ?
0 Kudos
Evgeny_F_Intel
Employee
1,110 Views

Can you provide full kernel code that fails.
How the vertices variable is defined?

0 Kudos
Polar01
Beginner
1,110 Views
Yes I can,
You can reach me at krys@polarlights.net, then I will send you a package to test...
Please, can you also sign a NDA ?
Regards
0 Kudos
Shiri_M_Intel
Employee
1,110 Views
Hi
Currently the support we give to the product is via the forum only. Therfor we can not sign NDA.
I suggest that you give us reproduction with problemtic lines in kernel without any IP senstive data.
Thanks, Shiri
0 Kudos
Polar01
Beginner
1,110 Views
Just try the following code in the "offline compiler" please. It will show you the error :
typedef struct{ float x,y,z;} Point;
typedef struct{ Point P;} Vertex;

__kernel void foo(__global Vertex* in, __global float4* out)
{
size_t tid = get_global_id(0);
out[tid] = vload4(tid, &in[0].P);
}
0 Kudos
Evgeny_F_Intel
Employee
1,110 Views
Thank for the code snapshot.

As i understand the main point here is function overloading issue.
The type of &in[0].P is '__global Point*', and it's not match any vloadn function defined by the spec. section 6.11.7. For that reason you should explicitly cast to __globalfloat*.

Doesit answer you problem?
0 Kudos
Polar01
Beginner
1,110 Views
Of course... :-)
Thanks for your support
0 Kudos
Reply