Posted by
Michael Bien on
Feb 19, 2011; 5:06pm
URL: https://forum.jogamp.org/upcoming-semantical-change-for-buffer-operations-tp2519021p2534420.html
On 02/19/2011 05:41 PM, Sven Gothel [via jogamp] wrote:
> On Saturday, February 19, 2011 17:31:50 Sven Gothel wrote:
>
> > On Thursday, February 17, 2011 21:30:07 Michael Bien [via jogamp]
> wrote:
> > >
> > > a more concrete example would look like:
> > >
> > > CLBuffer<FloatBuffer> src =
> > > context.createFloatBuffer(preparedNIOBuffer);
> > > CLBuffer<FloatBuffer> dst =
> > > context.createFloatBuffer(preparedNIOBuffer.capacity());
> > >
> > > int src_offset = 12; // ignore first 12 floats
> > > int dst_offset = 0;
> > > //now
> > > queue.putCopyBuffer(src, dst, src_offset*SIZEOF_FLOAT,
> > > dst_offset, (src.capacity()-src_offset)*SIZEOF_FLOAT);
> > >
> > > //after the change
> > > queue.putCopyBuffer(src, dst, src_offset, dst_offset,
> > > src.capacity()-src_offset);
> > >
> > > queue.finish();
> > >
> >
> > yup cool .. and as we discussed, the alignment / row-pitch values in
> bytes,
> > if appropriate / exists.
> >
>
> forgot to nitpick .. IMHO it's more an addition
> not a semantical change, since the original method signature will be
> still available right ?
>
> ~Sven
>
no. The signature will stay but the meaning will change.
Example signature:
public CLCommandQueue putWriteBuffer(CLBuffer<?> writeBuffer, boolean
blockingWrite){...}
(which is already now at least 4 times overloaded per function signature)
if you put a CLBuffer<FloatBuffer> as writeBuffer it will count 4bytes
as element size, a ByteBuffer as storage would count 1byte per element
accordingly.
I want that change too but first i want to be sure we thought through
all consequences. For example 2) of
http://forum.jogamp.org/upcoming-semantical-change-for-buffer-operations-tp2519021p2519021.html
could introduce bugs in client code.
example:
CLBuffer<FloatBuffer> over a 9 byte long CL memory region.
if you naively use the queue.copy(...) methods you will only be able to
copy the first 8bytes since you can not address the 9th byte.
3) There are also special meanings for ranges for example. range
{rangeX, rangeY, 1} would tell OpenCL that you are addressing a 2d
buffer instead of a 3d buffer. Just by looking at the spec you will
trigger a segfault if you try this with a FloatBuffer.
But i still think we can get the best of both... my current prototype
looks promising so far.
Sidenote:
you can always create a different view for your buffer:
CLBuffer<FloatBuffer> fb = ....;
CLBuffer<ByteBuffer> bb = b.cloneWith(bytebuffer); // view on the same
cl memory region
so.. if you know what you are doing its all fine. I just want to prevent
to introduce something with high bug potential for client code just to
make the api a bit nicer.
Thanks for all the comments!
-michael
--
- - - -
http://michael-bien.com