EDIT: Wo-ho - I overlooked your last post, sorry…
Of course you should not roll back to older drivers! If necessary, I would update the JOCL binaries for the new version.
I just quickly installed the latest drivers (280.26, Windows 32bit) and tested the “JOCLSample_1_1.java” from the Samples at http://jocl.org/samples/samples.html . It’s only a very small test with a very simple kernel, but it involves some of the features only available in OpenCL 1.1, and for me it worked with the NVIDIA platform (GeForce 8800) as well as the AMD Platform (using the CPU).
And to emphasize this: I did not want to say that it’s an issue of the NVIDIA OpenCL drivers. It might have been an incompatibility between the JOCL library and the latest version of the drivers. But from the first test, this does not seem to be the case. (Of course, there might be something wrong with JOCL, but at least it does not seem to be a general problem with the new drivers).
You’re right: JOCL intentionally is only a very, very thin layer around the OpenCL functions. It does not involve any additional error- or sanity checks and no additional convenience functions (although, I allocated the time for JOCL next week also in order to make another attempt for wrapping the Object-Oriented JOCL from http://jogamp.org/jocl/www/ around my low-level JOCL…).
What I wanted to say: I have also seen crashes of the Java VM. Nasty, nasty crashes But until now, in every case, I found out that I made a mistake in the kernel. In most cases, as I already mentioned, this happened due to null pointer accesses or writing outside of array bounds. OpenCL can detect pure compilation errors, but unfortunately, other errors will not cause a gracious ‘NullPointerException’ or ‘ArrayIndexOutOfBoundsException’ to be thrown, but instead vaporize the VM.
At the moment, it’s not possible to definitely say whether the reason for the error is inside JOCL or inside the kernel. One easy next step could be that you test one of the samples from the Website, to see whether it works for you in general. The following step could be that you provide a small example of a program that calls your kernel and reproducably crashes. (If you don’t want to post the code here, you can send me a PM or mail).
BTW: I have a strategy for writing own kernels, which of course is not applicable for every type of kernel, but helped me a lot in the beginning: I have created an abstract class which offers methods like the built-in OpenCL functions (“get_global_id(int dim)” etc…) and some additional helper functions, and which allows writing java code that is at least very similar to the final OpenCL code. I already started to extend this class in order to provide a “framework” for quick development of simple kernels (including benchmarking and debugging), but this is still far from being really applicable. Maybe one day I’ll find the time to extend and publish it…