JME-OpenCL interoperability

I am considering the idea of using opencl into my project for particular kinds of animation, so i read the opengl-opencl interoperability related page on the lwjgl wiki, and now I am wondering if there is a way to share the memory relative to a specific jmonkey spatial with an opencl kernel, without editing the jme core.
And if not, which classes are concerned with spatial rendering in JME?

HJME is abstracted from lwjgl or jogl or any other opengl wrapper, so

One possibility might be to create a copy(or extend) the lwjglrenderer class, and add some methods to gain access to those native objects, and set jme up to use your own renderer class instead.
A look at BufferUtils might also be worthwhile.

Thanks for the reply.

Actually i need only the id of the vertex buffer for sharing it from gl to cl, as it’s described here: , and jme has a method in NativeObject class that should return the id i’m looking for, so i wrote this code
that should move each vertex along the y axis.
It compiles without error, but vertices don’t move.

The weirdest thing is that if I switch device to CL_DEVICE_TYPE_CPU, it seems to work…

My suggestion would be,

share the buffer, read it back to cpu on opencl site
print buffer from jme side and from opencl site.

That way you can proove if the sharing is doing anything when running on gpu at all.
Then next phase then would be modify the buffer on jme side, and see if the changes are visible from opencl (eg do updates work that way)
Then try manipulating it from opencl and see if it is changed in JME side.

I can test your code on my machine tomorrow, aand see how it behaves there.

I’ve tried the same code on Opensuse 13.1 (with latest Catalyst driver+AMD APPSDK) and windows 7 (with the same drivers), and on Windows it works.
I can see the gpu as an opencl device with “clinfo” ( ), so it should be a driver issue…

Hm, I can try on my linux this evening, (as it is also catalyst +sdk) soo how it behaves there.
(I have the beta drivers installed, so the latest possible)

Also if you would have no gpu devie it would throw npe per frame (as my laptop does^^)

Actually I just saw that I can recompile mesa with opencl, lets see what that does.

There’s a problem in the code i posted above.
Actually I’m a bit confused, because in every example I’ve read, they refer to the vertex buffer as a float4 pointer, but in my cl code i must refer to it as a “float” pointer otherwise each transformation results in a weird deformation :\

This is the corrected code:

Anyway, it still doesn’t work on my linux installation, I’ve tried to write the position of every vertex into the result buffer, but at the end it is full of zeros…

Have you got any news about that?

Hm well not a good idea to compile a graficdriver yourself, thats the first thing found out.
(Had only white flickering on the screen after that and spend rest of the day recovering it :P)

Anyway from the genreal sound i would say you are missing some synchronisation fence, so it is up to the driver when it applies the changes.