- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?
Link Copied
9 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
2>
Can you give exact name of the dll?
Could you provide simple sample that reproduce the failure?
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you provide full kernel code that fails.
How the vertices variable is defined?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just try the following code in the "offline compiler" please. It will show you the error :
__kernel void foo(__global Vertex* in, __global float4* out)
typedef struct{ float x,y,z;} Point;
typedef struct{ Point P;} Vertex;
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);
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Of course... :-)
Thanks for your support
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