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
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.
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.
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.
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.
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.