Steps to reproduce:

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

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

By looking at OpenGL ES 3.0 spec, it says in section 3.8.3 "Texture Image Specification"
   
   "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>glCopyTexSubImage2D(0x00000000, 0, 0, 0, 0, 0, 4, 4);</Text>
  <Text>glGetError();</Text>
  <Text>// GL_NO_ERROR returned</Text>
  <Text>// ERROR: expected GL_INVALID_ENUM</Text>
</Section>

Similarly for glCopyTexSubImage3D()'s test case:

OpenGL ES 3.0 spec, it says in section 3.8.3 "Texture Image Specification"
   "[...] the target arguments of TexSubImage3D and CopyTexSubImage3D must be TEXTURE_3D or TEXTURE_2D_ARRAY."

This is a snip of dEQP-GLES3.functional.negative_api.texture.copytexsubimage3d test output:

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

Hope this helps,

Sam

I think we intentionally changed that behavior.  Aparently, it changes in 3.1 and in 4.2 so we just updated to the new behavior.  Laura will know more about that.  Reassigning...

OpenGL ES 3.1 still specifies GL_INVALID_ENUM.  See the "Errors" box on page 157 (page 174 of the PDF).

OpenGL 4.4 and GL_ARB_direct_state_access change the error to GL_INVALID_VALUE, but I believe this is a mistake.  I have submitted a spec bug.  Let's wait to hear back from Khronos before changing anything.  Since next week is GDC, it probably won't be until the following week.

Like 89311, 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 copy subtextures.  I'm currently testing my patch for this and will send it soon.

Again, like 89311, the spec change in errors thrown by *TexSubImage* is a separate issue.

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 :-)

Closing the bug report, thanks!