Posted by
Michael Bien on
Feb 23, 2011; 4:03pm
URL: https://forum.jogamp.org/glTexImage-performance-tp2555613p2560999.html
direct buffers can be much faster as heap allocated buffers. (but it
really depends on your application)
With direct ByteBuffers (and its views like FloatBuffer) have a fixed
address once they are allocated. The GC does not move them around (e.g.
as it would happen in the compaction phase). If you use direct buffers
we can just take the pointer to the buffer and proceed.
Non direct buffers (which are the equivalent of plain arrays) are
however much harder to deal with. We have to use
GetCritical/ReleaseCritical JNI funcitons which eather return a copy of
the buffer or drive the VM into a safepoint, stop the GC and give us the
pointer to the buffer in the heap. Both cases are quite bad esp because
they do not scale very well.
JOCL for example forces you to use direct NIO for all performance
critical operations but allows arrays/heap buffers for setup and non
perf relevant functions.
hope that helps a bit,
-michael
On 02/22/2011 10:18 PM, Ondrej [via jogamp] wrote:
>
> Hi guys, do you have any experience with glTextImage performance when using
> different Java IO buffer implementations?
>
> I am going to use data in FloatBuffer and quite large GL_R32F textures. I
> wonder how much the performance depends on buffer implementations (plain
> FloatBuffer, ByteBuffer.asFloatBuffer, direct/indirect, native order). Any
> suggestions? Maybe I will do some benchmarks.
>
> Ondrej
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
>
http://forum.jogamp.org/glTexImage-performance-tp2555613p2555613.html> To start a new topic under jogamp, email
[hidden email]
> To unsubscribe from jogamp, visit
http://michael-bien.com/