I found a couple of examples for use OpenCL with LWGL, which is the basis of JMonkey.
download
Fractal
1 000 000 3d Particles YouTube
And http://wiki.lwjgl.org/wiki/OpenCL_in_LWJGL
http://sabia.tic.udc.es/gc/Contenidos%20adicionales/trabajos/Opengl/LWJGL/interaccion.html#
If someone have more examples You can post here.
I think the compute stuff is pretty interesting however I think for JME we would have to write an api to support it before we could introduce it properly and this is something we might want to design first. We effectively need to abstract away some of the cumbersome parts of the LWJGL api/bindings just like we have for OpenGL at the moment.
Having the ability to write compute jobs of some kinda would be cool 
And quite simple tutorial for program to add two arrays
http://www.jeffheaton.com/2013/06/introduction-to-opencl-with-lwjgl/
How about AMD’s Aparapi? Here is an example of Aparapi in conjunction with JME:
Just Aparapi official Java bindings for Open Computing Language to AMD cards. JCUDA no oficial Java bindings for “Close” Computing Language to NVidia cards. But if somebody dont wants to know all standarts he’s looking for simpler solutions, at that difference in tests is 20%.
You also can used Java bindings for OpenCL - JOCL jocl.org - Samples
as you see more examples, than add two arrays. Although in my opinion LWGL realisation simply. And again familiarization of this examples for sure can require some LWGL knowledges.
Aparapi does have Nvidia support provided that you have an OpenCL 1.1+
driver for it as per the discussion here:
https://code.google.com/p/aparapi/issues/detail?id=160
Saying that this set of bindings is the basis of JMonkeyEngine is a bit misleading and disrespectful for the contributors who spend some time in maintaining the backends based on other sets of bindings. Thank you to act as what I do wouldn’t even exist. Moreover, a large part of this engine doesn’t deal with OpenGL and OpenAL directly.
gouessej I think that the basis of graphic engine (game engine) is a render engine. So I suppose LWGL is the basis of JMonkey.
The primary reason LWJGL exists is because there are many useful libraries and APIs that Java developers cannot use directly. OpenAL, OpenGL and OpenCL are characteristic examples; these APIs are implemented as platform-specific dynamically loaded libraries and are exposed as C function pointers. The method a JVM uses to call such functions is called JNI and LWJGL’s job is to make this process easier. Even though LWJGL provides many utilities to make the Java/C interaction cleaner and safer, it is a very low-level library and the Java methods follow the C counterparts precisely. 2.6.4 Basics of modern OpenGL (Part I) · LWJGL/lwjgl3-wiki Wiki · GitHub
As I understand initially Aparapi was suitable for AMD http://streamcomputing.eu/?s=Aparapi
nevertheless that OpenCL is Open Computing Language .
At first, JMonkeyEngine isn’t a game engine, there is no notion of NPCs for example. It’s a 3D engine mainly used for games but (almost?) nothing stops a developer from using it in a CAD software.
Secondly, look at its source code, only a small part of JMonkeyEngine directly talks to OpenGL, OpenGL ES and OpenAL.
Thirdly, if you looked at the source code, you would notice that there are several backends for the desktop environment and the embedded environment, only one of them use the set of Java bindings you mentioned (and misspelled) and only for the desktop environment, it’s not used under Android. Therefore, writing that this API is the basis of JMonkeyEngine is plain wrong as it’s totally possible to make it work without it and it’s what happens under Android.
Fourthly, there is already an experimental backend based on JogAmp that uses JOGL and JOAL. That’s why my suggestion of using JogAmp’s JOCL isn’t absurd to me.
Fifthly, I’m surprised of seeing numerous developers using JMonkeyEngine making wrong claims based on prejudices or unverified information or asking for support of an API that they don’t even know.
Sixthly, some things possible with OpenCL are doable with OpenGL compute shaders. In my humble opinion, this option should be explored even before supporting a more general-purpose computing language like OpenCL.
I agree with that.
Also i’ve never been able to make opencl works properly with my r9 270x under linux w/ proprietary drivers (e.g. buffer sharing between gl-cl doesn’t work while the same code on windows with same hw and drivers works), and i read about many other with similar problems, so i’m not sure if using it on production would be a good idea unless truly necessary.
As you can see in the official Khronos Group documentation, there are some similarities between OpenCL and OpenGL compute shaders. However, those shaders are called only on demand, not with other shaders linked to the current program. glDispatchCompute and glDispatchComputeIndirect must be exposed.
Moreover, OpenGL compute shaders seem to be easier to use and easier to support:
http://wili.cc/blog/opengl-cs.html
http://media.siggraph.org/education/conference/S2012_Materials/ComputeShader_1pp.pdf
You can even use such shaders in a ray tracer:
if they knew then not ask…
What do you mean exactly? If you don’t know an API enough to know at least what it offers, why asking for supporting it in JMonkeyEngine?
