Problem seems to be that with both deqp-gles2 and deqp-gles3 we are hitting the same format check path _mesa_es3_error_check_format_and_type. Checks done there are not valid with gles 2.0, we should be hitting _mesa_es_error_check_format_and_type instead.

Umm forget about comment #1, _mesa_es_error_check_format_and_type is for ES 1. What is strange about this bug is that if I move the dimensions check before texture_format_error_check_gles(), then all the tests pass. However it seems that texture_format_error_check_gles() test passes.

The issue here is that mesa is failing the format+type+internalFormat check for a test that expects to fail for invalid dimensions, which are checked later down the code in texsubimage_error_check().

The format+type+internalFormat is failing because we are using the internal format from the texture object instead of the effective internal format derived from the format+type:

Page 127, section "3.8 Texturing" of the GLES 3.0.4 spec says:

"if internalformat is a base internal format, the effective internal format is a sized internal format that is derived from the format and type for internal use by the GL. Table 3.12 specifies the mapping of format and type to effective internal formats. The effective internal format is used by the GL for purposes such as texture completeness or type checks for CopyTex* commands. In these cases, the GL is required to operate as if the effective internal format was used as the internalformat when specifying the texture data."

And since the internal format is GL_RGBA, a base internal format, we should resolve the effective internal format and use it in the validation, instead.

In this specific case, and per table 3.12, for format GL_RGB and type GL_UNSIGNED_BYTE, the effective internal format is GL_RGB8. With that value, the validation is ok and the test passes.   

I will write a patch for this and test for regressions. 

Thanks!

(In reply to Eduardo Lima Mitev from comment #3)
> The issue here is that mesa is failing the format+type+internalFormat check
> for a test that expects to fail for invalid dimensions, which are checked
> later down the code in texsubimage_error_check().
> 
> The format+type+internalFormat is failing because we are using the internal
> format from the texture object instead of the effective internal format
> derived from the format+type:
> 
> Page 127, section "3.8 Texturing" of the GLES 3.0.4 spec says:
> 
> "if internalformat is a base internal format, the effective internal format
> is a sized internal format that is derived from the format and type for
> internal use by the GL. Table 3.12 specifies the mapping of format and type
> to effective internal formats. The effective internal format is used by the
> GL for purposes such as texture completeness or type checks for CopyTex*
> commands. In these cases, the GL is required to operate as if the effective
> internal format was used as the internalformat when specifying the texture
> data."
> 
> And since the internal format is GL_RGBA, a base internal format, we should
> resolve the effective internal format and use it in the validation, instead.
> 
> In this specific case, and per table 3.12, for format GL_RGB and type
> GL_UNSIGNED_BYTE, the effective internal format is GL_RGB8. With that value,
> the validation is ok and the test passes.   
> 
> I will write a patch for this and test for regressions. 
> 
> Thanks!

ok cool, please CC me

Sent. http://lists.freedesktop.org/archives/mesa-dev/2015-August/091695.html

Eduardo's patch series fixes 59 dEQP tests with no regressions.

Nice work!

There is a high chance that the tests reported as regressed are actually buggy. See my bug report against dEQP here:

https://code.google.com/p/android/issues/detail?id=187348&thanks=187348&ts=1443083425

Also see these discussions during patch review for more context:

http://lists.freedesktop.org/archives/mesa-dev/2015-September/095154.html

the same sub tests keeps failing on HSW with the following configuration :

==Test Environment==
--------------------------------------------------
kernel: 4.3.0-rc5-drm-intel-nightly+
xorg-server-1.17.2
libdrm-2.4.65
xf86-video-intel-2.99.917
mesa-11.1.0-devel (git 6f39546)
libva-1.6.1
intel-driver-1.6.1
cairo-1.14.2

Mark dropped this test from his CI lists in

commit a6562934b4951a3e1b6032f6ea63068f27d584ab
Author: Mark Janes <mark.a.janes@intel.com>
Date:   Fri Mar 18 11:59:12 2016 -0700

    make new failure lists
    
    we are running dEQP in a completely new way.  We need to make new
    minimal failure sets from deqp.
    
    No meaningful regression history was present in the previous contents.

so I think we don't care about this bug any more? Perhaps it's already been fixed in the test suite (though I don't see evidence of that from the link in comment #7). Should we close this, Mark?

this was fixed by

5d64cae8427b090c42d6d38da7fb474b3ddd4eb0
mesa: Validate target before resolving tex obj in glTex(ture)SubImageXD