Bug 97567

Summary:	[SNB, ILK] ctl, piglit regressions in mesa 12.0.2rc1
Product:	Mesa	Reporter:	Mark Janes <mark.a.janes>
Component:	Drivers/DRI/i965	Assignee:	Emil Velikov <emil.l.velikov>
Status:	RESOLVED FIXED	QA Contact:	Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity:	blocker
Priority:	medium	CC:	beandras90, jason
Version:	12.0
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
URL:	96dfed49e47eac7afc100e5b8d3b316dd6652fb6
Whiteboard:
i915 platform:		i915 features:

Description Mark Janes 2016-09-01 19:24:20 UTC

Mesa 48e9ecc47f078cba3f56694e4583003681717410 regressed several tests
Author:     Jason Ekstrand <jason@jlekstrand.net>
Commit:     Emil Velikov <emil.l.velikov@gmail.com>
i965/miptree: Set logical_depth0 == 6 for cube maps

This matches what we do for cube maps where logical_depth0 is in number of
face-layers rather than number of cubes.  This does mean that we will
temporarily be setting the surface bounds too loose for cube map textures
but we are already setting them too loose for cube arrays and we will be
fixing that in the next commit anyway.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Cc: "12.0 11.2 11.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit e19b7f7f1b5d6a1d325c0129d6d6b9da6234330a)

Regressions:

[SNB]
es3-cts.gtf.gl3tests.npot_textures.npot_cubemap_render
es3-cts.gtf.gl3tests.npot_textures.npot_pbo_tex_sub_image_2d
es3-cts.gtf.gl3tests.npot_textures.npot_tex_sub_image_2d
es3-cts.gtf.gl3tests.shadow.shadow_execution_frag
es3-cts.gtf.gl3tests.texture_storage.texture_storage_texture_as_framebuffer_attachment
piglit.shaders.glsl-fs-texturecube-2-bias
piglit.shaders.glsl-fs-texturecube-bias
piglit.spec.!opengl 3_0.sampler-cube-shadow
piglit.spec.arb_shader_texture_lod.execution.tex-miplevel-selection *gradarb cube
piglit.spec.arb_shader_texture_lod.execution.tex-miplevel-selection *lod cube
piglit.spec.arb_texture_cube_map.cubemap-shader bias
piglit.spec.arb_texture_cube_map.cubemap-shader lod
piglit.spec.glsl-1_20.execution.tex-miplevel-selection gl2.texture(bias) cube
piglit.spec.glsl-1_30.execution.tex-miplevel-selection texture() cubeshadow
piglit.spec.glsl-1_30.execution.tex-miplevel-selection texture(bias) cube
piglit.spec.glsl-1_30.execution.tex-miplevel-selection texture(bias) cubeshadow
piglit.spec.glsl-1_30.execution.tex-miplevel-selection texturegrad cube
piglit.spec.glsl-1_30.execution.tex-miplevel-selection texturegrad cubeshadow
piglit.spec.glsl-1_30.execution.tex-miplevel-selection texturelod cube

[ILK]
piglit.shaders.glsl-fs-texturecube-bias
piglit.shaders.glsl-fs-texturecube-2-bias
piglit.spec.glsl-1_20.execution.tex-miplevel-selection gl2.texture(bias) cube
piglit.spec.arb_texture_cube_map.cubemap-shader bias
piglit.spec.arb_shader_texture_lod.execution.tex-miplevel-selection *gradarb cube
piglit.spec.arb_shader_texture_lod.execution.tex-miplevel-selection *lod cube

Comment 1 Emil Velikov 2016-09-02 13:33:02 UTC

Seems like the next commit wasn't tagged for -stable and I've missed it.

Namely:

commit 96dfed49e47eac7afc100e5b8d3b316dd6652fb6
Author: Jason Ekstrand <jason.ekstrand@intel.com>
Date:   Mon Jul 18 16:25:12 2016 -0700

    i965: Stop muging cube array lengths by 6

Jason, we want this in -stable don't we ?

Mark, if there's a few cycles left in the CI can you apply this on top and give re-test ? I'm reviving my old SNB machine so it can take an hour to so to test things.

Comment 2 Mark Janes 2016-09-02 17:45:31 UTC

I don't think it's just a missing patch.  Jason commented on IRC:
<jekstrand> janesma: Ugh... That regression goes deeper than it looks...

It may be more sensible to remove the series from the stable branch than to try to fix it now.  Jason can speak to the question of whether getting this series into stable should pre-empt other ongoing efforts.

Comment 3 Emil Velikov 2016-09-02 18:22:02 UTC

I second that. I've gave it a closer look and a lot of that depends on a serious rework in order to reuse ISL on older gen.

I've got my SNB machine in action (until it starts restarting on its own again), so I'll pull things and check that things are in shape.

Comment 4 Jason Ekstrand 2016-09-03 02:19:25 UTC

Yeah, fixing it properly is going to take surgery.  I think it's best to go for "no new failures" than "different failures" at the moment.  In other words, we should just revert it and fix it later if we decide it's important.

What's really confusing is why it only shows up on Sandy Bridge and earlier.

Comment 5 Emil Velikov 2016-09-13 10:56:58 UTC

By reverting the commit for 12.0 and we introduced a regression - bug 97781.

Marking this as resolved for the moment, although we might need to part apply for non SNB/ILK hardware.

Mark, does the CI check gen4 hardware? From a quick look those should be affected here.

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.