[SOLVED] Java applet: jocl operations stop java3d

Java applet: jocl operations stop java3d

Jocl(opencl wrapper) kernel running makes java3d output disabled. When opencl finishes, java3d continus working.

How can I let Opencl(jocl) and opengl(java3d) work together? I need some kind of command that tells "its opencl time" and when it finishes it tells "its opengl time now".

Somehow java3D Jpanel freezes and becomes greyed when opencl is working.

I did some tracing and found out that java3D is harrassing opencl(jocl), jmonkey engine 3.0 doesnt do that. Another try showed jmonkey doing same thing. Suddenly all particles positions stop updating by opencl then all positions go 0,0,0.

Using unique context, program, id, ... for each device.

How error looks like: while galaxy is rendered smoothly, suddenly all particles get projected on a plane which I did not create then a few seconds after the plane gets projected onto a line and finally that line gets projected onto a spot. All these must be because of buffers x[] y[] z[] start getting zero for all elements.

Edit: lower gpu operating frequencies make the error less frequent. Could this be pushing the gpu harder than furmark because doing calculations in local to work faster? Or is this a timing/ accessing priority issues between jocl/jmonkey/java3d ? All other programs including furmark, are stable at 1225MHz(hd7870 hawk) but this is likely more stable at only 1000MHz(AMD default of hd7870) or looks unstable as buffers get destroyed by garbage collection faulty ??

Aparapi(opencl wrapper for java) was never a problem and worked fine at 1200MHz Even got a "driver stopped functioning and recovered" error. Catalyst 13.3 beta. Jocl 1.5.1 and tired 1.5.2. Catalyst 13.4 whql does the same.

Putting System.gc(); just before the kernel-repeating loop makes the erroneous thing immediately, there must be a garbage collection thing I missed

With some tracing: clCreateBuffer method has a problem with garbage collection

Edit: Solved the issue. Buffer created by clCreateBuffer in main thread seems as a garbage(to be collected) for sub-threads when CL.CL_MEM_USE_HOST_PTR property is used. CL.CL_MEM_COPY_HOST_PTR solves the problem in exchange of %1-%2 performance loss

Thanks.

Solution