Login  Register

Re: CommandQueue/Buffer change request

Posted by Michael Bien on Nov 21, 2011; 8:57pm
URL: https://forum.jogamp.org/CommandQueue-Buffer-change-request-tp3525736p3526024.html


On 11/21/2011 08:19 PM, Matthias [via jogamp] wrote:
> Hello,
Hi,

>
> first, you have done great work with your libraries especially OpenCL.
thank you for using it ;)

>
> But ... i have a problem when writing data to a device:
>
> in CLCommanQueue you do:...
>
> public CLCommandQueue putWriteBuffer(...
> ...
> cl.clEnqueueWriteBuffer(
>     ID, writeBuffer.ID, clBoolean(blockingWrite),
>     0, writeBuffer.getNIOSize(), writeBuffer.buffer,
>     conditions, conditionIDs, events==null ? null : events.IDs);
> ...
>
yeah, right. what have i thought? Lets see. Read+Write have all the
offset missing.

Thanks for bringing this up, the more recent methods like writeRect
however have offsets.

> is it possible to add a method in which the offset and length of the
> copy operation can be set,
> or is it possible to replace writeBuffer.getNIOSize() with
> writeBuffer.limit() .. and offset 0 with .mark()?
> So that buffers can be partially written to a device.
well. Problem here is that the NIO buffer is just the java
representation of the device buffer. It can be the same buffer but quite
often it is just a vehicle to move data between java and the device. So
you can have multiple CLBuffer objects with different NIO buffers
pointing to the same CL buffer (in this case buffer.ID would be the
identical all buffers; see buffer.cloneWith(nioBuffer)).

so we would have 2 offsets and 2 ranges for the 1D case. One for the
device buffer and one taken from the nio buffer.

The position of the nio buffer is already taken into account in the low
level binding (generated code). The range is an argument in the
read/write method.

so what is missing?
device buffer offset to write to or copy from

>
> regards

I'll fix this,
thanks
michael

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