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.
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
As i understand the main point here is function overloading issue. The type of &in.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*.