Why does NIO buffer have to be direct?

When using a non-direct NIO buffer I get an IllegalArgumentException: buffer is not direct

Why is it not possible to use a non direct buffer?

  On 06/15/2011 06:44 PM, barno [via jogamp] wrote:
>
> When using a non-direct NIO buffer I get an IllegalArgumentException: buffer
> is not direct
>
> Why is it not possible to use a non direct buffer?
>
>

hi barno,

most of the api only allows direct buffers for performance reasons
(primarily the command queue and all memory objects).

direct memory never moves in the heap which means jocl doesn't have to
interfere with the gc (critical locks) or copy objects before passing
the memory as pointer to OpenCL. Regular heap allocated buffers are
basically arrays which behave like normal objects. The GC may defragment
or just move the objects around in the heap (e.g new to old gen)...
using pointers without expensive locks wouldn't be a good idea under
those conditions.

if you are using lots of small buffers and worry about allocation
performance take a look at CachedBufferFactory.

regards,
michael

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

the reason why I was asking is that I have most of the data I want to transfer to the GPU already located in an array on the heap. Just wrapping a buffer around it and saving memory (and perhaps copy time) sounded advantageous to me. I understand the performance advantage you get from using direct buffers under most circumstances, but still I would rather not be forced to use direct buffers every time. Perhaps you could change the behavior from throwing an exception to just warning the user?

btw. I love your responsiveness and, of course, the library :-)

  On 06/15/2011 08:07 PM, barno [via jogamp] wrote:
> the reason why I was asking is that I have most of the data I want to
> transfer to the GPU already located in an array on the heap. Just wrapping a
> buffer around it and saving memory (and perhaps copy time) sounded
> advantageous to me. I understand the performance advantage you get from
> using direct buffers under most circumstances, but still I would rather not
> be forced to use direct buffers every time. Perhaps you could change the
> behavior from throwing an exception to just warning the user?
its not that simple (if i would remove the checks you would get a
segfault earlier or later). Allowing heap buffers would require two
generated code paths in the c and java parts of the binding - now we
have one very fast path (take the pointer and pass it to CL). Its a
tradeoff between function call overhead and ease of use. I still think
its worth to force the client code (for the performance critical api)
into the fast path since the consequence is rather cosmetical
(buffer.get(i) vs array[i] and buffer.put(i, v) vs array[i] = v).

i ended up with this assumption:
  - if performance is an requirement the application would use direct
nio in the first place
  - if not the app wouldn't use CL or just copy it from array to buffer :)

as so often you sadly can't make everyone happy :(

> btw. I love your responsiveness and, of course, the library :-)
>
thanks, very appreciated :)

-michael

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