Bug 91582

Summary: Regression in DEQP gles2.functional.negative_api.texture.texsubimage2d_neg_offset
Product: Mesa Reporter: Mark Janes <mark.a.janes>
Component: Drivers/DRI/i965Assignee: Intel 3D Bugs Mailing List <intel-3d-bugs>
Status: RESOLVED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium CC: elima, mark.a.janes
Version: gitKeywords: bisected
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Mark Janes 2015-08-07 16:32:05 UTC
mesa 03b7221dbb93e2439f30b2e0918f6215eb741979 regressed the following tests:

deqp-gles2.functional.negative_api.texture.texsubimage2d_neg_offset
deqp-gles2.functional.negative_api.texture.texsubimage2d_offset_allowed

The tests regressed on all tested platforms (byt, hsw, bdw, snb).

-------- test output -----------
/tmp/build_root/m64/opt/deqp/modules/gles2/deqp-gles2 --deqp-case=dEQP-GLES2.functional.negative_api.texture.texsubimage2d_neg_offset --deqp-surface-type=fbo --deqp-log-images=disable --deqp-surface-width=100 --deqp-surface-height=100
dEQP Core 2014.x (0xcafebabe) starting..
  target implementation = 'DRM'

Test case 'dEQP-GLES2.functional.negative_api.texture.texsubimage2d_neg_offset'..
Test case duration in microseconds = 2165 us
  Fail (Got invalid error)

DONE!

Test run totals:
  Passed:        0/1 (0.0%)
  Failed:        1/1 (100.0%)
  Not supported: 0/1 (0.0%)
  Warnings:      0/1 (0.0%)

Standard Error

Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(format = GL_RGB, type = GL_UNSIGNED_BYTE, internalformat = GL_RGBA)
Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(format = GL_RGB, type = GL_UNSIGNED_BYTE, internalformat = GL_RGBA)
Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(format = GL_RGB, type = GL_UNSIGNED_BYTE, internalformat = GL_RGBA)
--------------------------------
Comment 1 Tapani Pälli 2015-08-14 06:43:35 UTC
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.
Comment 2 Tapani Pälli 2015-08-14 07:15:46 UTC
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.
Comment 3 Eduardo Lima Mitev 2015-08-14 08:38:10 UTC
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!
Comment 4 Tapani Pälli 2015-08-14 11:12:05 UTC
(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
Comment 6 Mark Janes 2015-09-04 17:48:54 UTC
Eduardo's patch series fixes 59 dEQP tests with no regressions.

Nice work!
Comment 7 Eduardo Lima Mitev 2015-09-24 09:03:32 UTC
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
Comment 8 Humberto Israel Perez Rodriguez 2015-10-22 18:15:04 UTC
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
Comment 9 Matt Turner 2016-11-02 19:52:57 UTC
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?
Comment 10 Mark Janes 2016-11-02 21:05:50 UTC
this was fixed by

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

bug/show-multiple.html.tmpl processed on Jan 21, 2017 at 21:40:18.
(provided by the Example extension).