Reply – Re: Why does NIO buffer have to be direct?
Your Name
or Cancel
In Reply To
Re: Why does NIO buffer have to be direct?
— by Michael Bien Michael Bien
  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 :)