Bug 89311

Steps to reproduce:

$ cd <deqp-home>
$ cd modules/gles3
$ ./deqp-gles3 -n dEQP-GLES3.functional.negative_api.texture.compressedtexsubimage2d

After looking into it, I found that the test is expecting to receive a GL_INVALID_ENUM error when calling glCompressedTexSubImage2D() with target different than GL_TEXTURE_2D and GL_TEXTURE_CUBE_MAP_*. The test calls glCompressedTexSubImage2D() with target = 0.

By looking at OpenGL ES 3.0 spec, it says in section 3.8.3 "Texture Image Specification"
   
   "void CompressedTexSubImage2D (enum target, int level, int xoffset, int yoffset, sizei width, sizei height, enum format, sizei imageSize, const void *data );
   [...]
   "The target, level, xoffset, yoffset, zoffset, width, height, and depth parameters have the same meaning as in TexSubImage2D and TexSubImage3D."

And TexSubImage2D() part says:

   "The target arguments of TexSubImage2D and CopyTexSubImage2D must be one of TEXTURE_2D, TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z,"

Also from the same spec, section 2.5 "GL Errors"

"If a command that requires an enumerated value is passed a symbolic constant that is not one of those specified as allowable for that command, the error INVALID_ENUM is generated."

This is a snip of the test output:

 <Section Name="" Description="GL_INVALID_ENUM is generated if target is invalid.">
  <Text>glCompressedTexSubImage2D(0x00000000, 0, 0, 0, 0, 0, 0x00009274, 0, 0x0000000000000000);</Text>
  <Text>glGetError();</Text>
  <Text>// GL_NO_ERROR returned</Text>
  <Text>// ERROR: expected GL_INVALID_ENUM</Text>
 </Section>

Hope this helps,

Sam

See my comment on bug #89312.  I believe that applies here as well.

I've sent out a patch to fix this just now.  The root cause was that target checking must take place prior to calling _mesa_get_current_texture_object, and this necessitated splitting target checking out of the main error-checking function for compressed subtextures.

In regards to the spec change in the errors thrown by *TexSubImage* functions, that is a separate issue that involves conformance to DSA and gl 4.4.

I confirm that they are fixed in master branch.

I was about to tell that the fixes should be in mesa-10.5 branch but you already forward them to mesa-stable mailing list :-)

Closing the bug report, thanks!