Bug 111431

Summary: [bisected][regression][icl] dEQP GLES3 texsubimage3d_depth failures
Product: Mesa Reporter: Clayton Craft <clayton.a.craft>
Component: Drivers/Gallium/IrisAssignee: Kenneth Graunke <kenneth>
Status: RESOLVED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium Keywords: bisected, regression
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Clayton Craft 2019-08-19 17:37:59 UTC
The following dEQP tests are now failing on ICL + iris:
    dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth24_stencil8_2d_array
    dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth32f_stencil8_2d_array
    dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth_component32f_2d_array
    dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth_component24_2d_array


stdout/err:
glClearColor(0.125, 0.25, 0.5, 1);
glClear(GL_DEPTH_BUFFER_BIT|GL_STENCIL_BUFFER_BIT|GL_COLOR_BUFFER_BIT);
glGenTextures(1, 0x00007fff91da4b7c);
// textures = { 247 }
glBindTexture(GL_TEXTURE_2D_ARRAY, 247);
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
glGetError();
// GL_NO_ERROR returned
glTexImage3D(GL_TEXTURE_2D_ARRAY, 0, GL_DEPTH24_STENCIL8, 57, 44, 5, 0, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca8d290d0);
glTexImage3D(GL_TEXTURE_2D_ARRAY, 1, GL_DEPTH24_STENCIL8, 28, 22, 5, 0, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca8d12e20);
glTexImage3D(GL_TEXTURE_2D_ARRAY, 2, GL_DEPTH24_STENCIL8, 14, 11, 5, 0, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca83fd1e0);
glTexImage3D(GL_TEXTURE_2D_ARRAY, 3, GL_DEPTH24_STENCIL8, 7, 5, 5, 0, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca8771d10);
glTexImage3D(GL_TEXTURE_2D_ARRAY, 4, GL_DEPTH24_STENCIL8, 3, 2, 5, 0, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca8744450);
glTexImage3D(GL_TEXTURE_2D_ARRAY, 5, GL_DEPTH24_STENCIL8, 1, 1, 5, 0, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca85647f0);
glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 0, 28, 7, 2, 23, 21, 3, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca8b2c130);
glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 1, 3, 4, 2, 20, 12, 2, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca8a05660);
glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 2, 0, 10, 4, 3, 1, 1, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca85647f0);
glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 3, 0, 0, 1, 3, 4, 4, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca89edde0);
glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 4, 0, 1, 0, 2, 1, 4, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca83c5670);
glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 5, 0, 0, 1, 1, 1, 4, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, 0x562ca85647f0);
glGetError();
// GL_NO_ERROR returned
Image comparison failed: max difference = (127, 0, 0, 0), threshold = (2, 2, 2, 2)



Bisected to the following commit:

commit f741de236b5fa5522d8749a4b3e6d994fb98c630
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Wed Aug 14 13:54:55 2019 -0700

    isl: Enable Unorm Path in Color Pipe
Comment 1 Clayton Craft 2019-08-23 18:24:34 UTC
These also seem to be failing from that commit:

dEQP-GLES3.functional.texture.specification.texstorage2d.format.depth24_stencil8_2d
dEQP-GLES3.functional.texture.specification.texstorage2d.format.depth32f_stencil8_2d
dEQP-GLES3.functional.texture.specification.texstorage2d.format.depth_component24_2d
dEQP-GLES3.functional.texture.specification.texstorage2d.format.depth_component32f_2d
dEQP-GLES3.functional.texture.specification.texstorage3d.format.depth24_stencil8_2d_array
dEQP-GLES3.functional.texture.specification.texstorage3d.format.depth32f_stencil8_2d_array
dEQP-GLES3.functional.texture.specification.texstorage3d.format.depth_component24_2d_array
dEQP-GLES3.functional.texture.specification.texstorage3d.format.depth_component32f_2d_array
Comment 2 Kenneth Graunke 2019-08-27 00:48:07 UTC
This should be fixed by:

commit 2e1be771e47adf1d06901283ffb8df0d83f28b3c
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Fri Aug 23 17:32:06 2019 -0700

    isl: Don't set UnormPathInColorPipe for integer surfaces.

I am unclear what the underlying issue is, but setting this bit shouldn't actually do anything particularly useful for integer formats.  If it introduces any precision issues, it could definitely affect our bit-for-bit copies (via blorp_copy), which was what was causing this test to fail.  I verified that denying it for integer formats doesn't regress performance in Manhattan 3.0 on i965, which was the largest gain from the original patch.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.