OpenCL release buffer object

0
votes

I found strange problem in my program using OpenCL.

My device is android smartphone equipped with arm mali.

So i use jni for executing OpenCL kernels.

The host(java) side calls native functions.

Then. native(c++) function sets environment for GPGPU usage.

creating buffers, setting up argument, and so on..

Do some jobs in GPGPU

after GPGPU execution,It write values back to native side, and it goes to host side.

I made my program native function internalize buffer,values every time.

But it does not release buffer after native(c++) function execution ended.

It holds value itself.

So if call native function again, it write value after previously written value.

Java ->>> Cpp ->>> Cl(increment some value buffer to 7) ->>> cpp(in this point, buffer should be deleted but it's not) ->>> java ->>> cpp ->>> Cl(increment 7 to 14) ->>>.....

In many document on the web, people said "you don't need release buffer, it is done by device automatically"

I didn't declared buffer as static,so it should be validate within single execution time.

How can i release buffer manually?

1
androidc++android-ndkopencl
It's hard for anyone to reason about it without seeing your code. Note that releasing a buffer is different than zeroing its contents. If you had a buffer (let's say it started at 0), you add 7 to it, then released it, then allocated another buffer of the same size, the runtime might give you the same memory, which still has 7 in it. You add 7 again, yielding 14. Don't assume new buffers are filled with 0; they are probably leftover data. - Dithermaster
thank you for comment, you we're right. I thought that if i release buffer then it lost their data and filled with 'zero' automatically, it was very helpful. - eclipse0922

1 Answers

2
votes

Always call clReleaseMemObject() to release CL buffer object or image object, after you finish your CL part and are ready to return the results to JAVA part. Otherwise the behavior of the buffer/image are not defined. Anything could happen, such as memory leakage, crash or else.