Posted by Michael Bien on Feb 17, 2011; 1:14pm
URL: https://forum.jogamp.org/upcoming-semantical-change-for-buffer-operations-tp2519021.html

Hello everyone,

we discussed yesterday on the jogamp XMPP channel a semantical change i would like to implement very soon, here is the idea:

all buffer operations expect params like offsets, sizes, ranges etc to be specified as bytes. This is ok but we can do better in my opinion.
CLMemory and its direct subclasses CLBuffer and CLImage support having a optional nio buffer as host-side storage for the device-side buffer. This buffer can be any subclass of java.nio.Buffer, speak FloatBuffer, DoubleBuffer, ByteBuffer etc. The change would make those buffer operations buffer type agnostic. A queue.putReadBufferRect(aCLBufferWithFloatBufferStorage, origin, range, elements) would expect counting in floats (buffer elements) instead of bytes.

example from spec:
http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/clEnqueueReadBufferRect.html
https://jogamp.org/deployment/webstart-next/javadoc/jocl/javadoc/com/jogamp/opencl/CLCommandQueue.html#putReadBufferRect%28com.jogamp.opencl.CLBuffer,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20int,%20boolean,%20com.jogamp.opencl.CLEventList,%20com.jogamp.opencl.CLEventList%29

however there would be some implications/issues:
1) in some situations you will have to mix elements with bytes (CL functions with row_pitch, slice_pitch offsets for example, see spec link above)
2) in other cases you may have a buffer which is not evenly dividable by element_size, copying the buffer by specifying the size in elements may be problematic

1) is not preventable, however i would see the usage of pitch params as corner case and not what you will have to care about in most applications.
2) this is another corner case but can cause confusion

1) 2) are both without further api change solvable. It is already possible to create multiple views of a single CLBuffer:
https://jogamp.org/deployment/webstart-next/javadoc/jocl/javadoc/com/jogamp/opencl/CLBuffer.html#cloneWith%28T%29
so you could switch to a CLBuffer with ByteBuffer storage or even use both views at the same time to access it once via elements and once via bytes.

This could confuse a bit but i believe only if you deal with one of the corner cases above. (you know make the first 80% easy and the remaining 20% possible :) )

What do you think? go/nogo?
comments appreciated,

best regards,
michael


--
http://michael-bien.com/