glTexImage performance

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

Using ByteBuffer.asFloatBuffer or directly FloatBuffer is the same thing. Simply call Buffers.newDirectFloatBuffer() and you will get a direct float buffer in native order which is the fastest solution.

Thanks, the class com.jogamp.common.nio.Buffers looks very interesting and useful.

As far I found out that the buffer implementation for glTexImage can be both direct and indirect. If it is indirect it must backed by array. For example ByteBuffer.allocate(512*512*4).asFloatBuffer() throws exeception:

java.lang.UnsupportedOperationException
        at java.nio.FloatBuffer.array(FloatBuffer.java:940)
        at com.jogamp.common.nio.Buffers.getArray(Buffers.java:371)
        at com.jogamp.opengl.impl.gl4.GL4bcImpl.glTexImage2D(GL4bcImpl.java:23832)

Direct buffer must be in native order. If it is not in native order glTextImage2D works but uploaded texture is corrupted.

Looks like no big performance differences whether using direct or indirect buffers. (tested on notebook with poor graphic card)

By the way, how can I see the code at GL4bcImpl.java:23832 ? Cound not found it in repositories. Is this the part of code which is generated by gluegen?

Yes this is generated source code.

Ondrej wrote

By the way, how can I see the code at GL4bcImpl.java:23832 ? Cound not found it in repositories. Is this the part of code which is generated by gluegen?

Yes, GL4bcImpl.java is generated by gluegen as part of the build process. The method in your stack trace is this:

  /** Entry point to C language function: <code> void {@native glTexImage2D}(GLenum target, GLint level, GLint internalFormat, GLsizei width, GLsizei height, GLint border, GLenum format, GLenum type, const GLvoid *  pixels); </code> <br>Part of <code>GL_VERSION_1_0</code>   */
  public void glTexImage2D(int target, int level, int internalFormat, int width, int height, int border, int format, int type, Buffer pixels)  {

    checkUnpackPBODisabled(true);
    Buffers.rangeCheckBytes(pixels, imageSizeInBytes(format, type, width            , height            , 1    , false));
    boolean pixels_is_direct = pixels != null && Buffers.isDirect(pixels);
    final long __addr_ = ((GL4bcProcAddressTable)_context.getGLProcAddressTable())._addressof_glTexImage2D;
    if (__addr_ == 0) {
      throw new GLException("Method \"glTexImage2D\" not available");
    }
        dispatch_glTexImage2D1(target, level, internalFormat, width, height, border, format, type, pixels_is_direct ? pixels : Buffers.getArray(pixels), pixels_is_direct ? Buffers.getDirectBufferByteOffset(pixels) : Buffers.getIndirectBufferByteOffset(pixels), pixels_is_direct, __addr_);
  }

Line 23832 is dispatch_glTexImage2D1(), which is the native function.

Ondrej wrote

Looks like no big performance differences whether using direct or indirect buffers. (tested on notebook with poor graphic card)

I'd expect higher performance when reading a file into a texture when it's a direct buffer, since Java should be able to use native I/O. You might have to read tons of data to see a difference, though.

  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:

Thanks for explanations to all. If I find something interesting about texture upload performance, I will try to post it here.

On Thursday, February 24, 2011 12:52:31 Ondrej [via jogamp] wrote:
>
> Thanks for explanations to all. If I find something interesting about texture
> upload performance, I will try to post it here.

you may also try this offthread using PBO/DMA xfers,
afaik Wade gave some examples a while ago ..

As Michael mentioned, try o use a huge nio heap,
where you slice from .. we have such a factory under construction.
You may peek into PMVMatrix (jogl) as well.

~Sven