Bug 1220

Crap, we can't edit comments..

anyway, here it's the api doc https://www.opengl.org/sdk/docs/man3/xhtml/glTexSubImage3D.xml

void glTexSubImage3D(GLenum target,  GLint level,  GLint xoffset,  GLint yoffset,  GLint zoffset,  GLsizei width,  GLsizei height,  GLsizei depth,  GLenum format,  GLenum type,  const GLvoid * data);

"For three-dimensional textures, the z index refers to the third
            dimension. For two-dimensional array textures, the z index refers to
            the slice index.
"

Implementation example:
  public void glTexSubImage3D(int target, int level, int xoffset, int yoffset, int zoffset, int width, int height, int depth, int format, int type, Buffer pixels)  {
    checkUnpackPBOUnbound(true);
    Buffers.rangeCheckBytes(pixels, 
                imageSizeInBytes(format, type, width, height, depth, false));
    ...

+++

Spec:

"glTexSubImage3D redefines a contiguous subregion of an existing three-
dimensional or two-dimensioanl array texture image.
The texels referenced by data replace the portion of the
existing texture array with 
  x indices xoffset and xoffset+width-1, inclusive,
  y indices yoffset and yoffset+height-1, inclusive
  z indices zoffset and zoffset+depth-1, inclusive"

Further, as Giuseppe mentioned:

"For three-dimensional textures, the z index refers to the third
dimension. For two-dimensional array textures, the z index refers to
the slice index."
            
+++

Hence implementation completely ignores the [xyz] offset
while calculating the required minimum-size of the given buffer!

Impact: Application always needs to supply a fully-texture-sized buffer,
where only the updated region needs to be supplied in the buffer.

+++

Wonder how this bug could have survived undetected that long ..

Further more, we need to range-check and PBO check 'glTextureSubImage[123]D',
see Bug 1233.

Invalidating my comment 2, guess I was reading the spec to quickly
w/o thinking (too later probably).

  x indices xoffset and xoffset+width-1, inclusive,
  y indices yoffset and yoffset+height-1, inclusive
  z indices zoffset and zoffset+depth-1, inclusive"

this means that we simply have to calculate the imageSize
on the width x height x depth, as we do it already!

reverting the bug description to original.

(In reply to Giuseppe Barbieri from comment #0)
> glTexSubImage3D interprets the z index as third dimension although a 2d
> array texture has been provided
> 
> ByteBuffer data = GLBuffers.newDirectByteBuffer(256*256);
> 
> gl4.glTexSubImage3D(GL4.GL_TEXTURE_2D_ARRAY, 0, 0, 0, 0, 256, 256, 2,
> GL_RED_INTEGER, GL_UNSIGNED_BYTE, data);
> 
> Caused by: java.lang.IndexOutOfBoundsException: Required 131072 remaining
> bytes in buffer, only had 65536
> 	at com.jogamp.common.nio.Buffers.rangeCheckBytes(Buffers.java:1056)
> 	at jogamp.opengl.gl4.GL4bcImpl.glTexSubImage3D(GL4bcImpl.java:7979)


You seem to use the API wrong,
i.e. you probably want to update slice index 2
using your TEXTURE_2D sub-image.
The depth should be 1 in this case, of course!

(In reply to Sven Gothel from comment #5)
> 
> You seem to use the API wrong,
> i.e. you probably want to update slice index 2
> using your TEXTURE_2D sub-image.
> The depth should be 1 in this case, of course!

like this:

gl4.glTexSubImage3D(GL4.GL_TEXTURE_2D_ARRAY, 0, 0, 0, 2, 256, 256, 1,
GL_RED_INTEGER, GL_UNSIGNED_BYTE, data);

as mentioned above, no offset is even being used while calculating the
image size for the buffer range check.

I don't get it, if I want to update layer 2 of a 256x256 red/unsigned byte texture I need to supply a 256*256*1=65536 bytes buffer, not a 131072-bytes one.

(In reply to Giuseppe Barbieri from comment #7)
> I don't get it, if I want to update layer 2 of a 256x256 red/unsigned byte
> texture I need to supply a 256*256*1=65536 bytes buffer, not a 131072-bytes
> one.

131072 / 2 = 256*256

You put in factor 2, by depth argument, which must be 1 instead,
since you only want to update 1 layer. 

Read the comment above.

Ah, now I got what you meant, I'll try next week

thanks

Yep, you were right, Sven, sorry for the trouble

Thanks