[Mesa-dev] i965: GPU hang after re-creating miptrees for 1DArray texture targets

[Iago Toral]

On Wed, 2015-01-28 at 10:48 +0100, Iago Toral wrote:
> Hi,
> 
> I think I have found a bug that can even produce a GPU hang in the i965
> code that handles 1DArray textures and that is related to the miptree
> structure that supports them. At least IvyBridge and Haswell are
> affected.
> 
> The problem happens when we need to drop the initial miptree to create a
> new one in intel_finalize_mipmap_tree (intel_tex_validate.c). This can
> happen normally when we have added mipmaps to the texture and configured
> the sampler with a mipmap filter, in that case the code has some
> conditions to check for this situation, then calls
> intel_miptree_release(&intelObj->mt) and then re-creates the miptree
> with the new parameters.
> 
> The problem happens when we re-create miptrees for 1DArray textures and
> seems to happen always as far as I can tell. The way to reproduce this
> is simple, it is enough to force the re-creation of the miptree by
> forcing the call to intel_miptree_release in intel_finalize_mipmap_tree.
> If we do that, various piglit tests that deal with 1DArray textures
> fail. Some examples include:
> 
> shader_runner tests/spec/ext_texture_array/render-1darray.shader_test
> bin/copyteximage 1D_ARRAY -fbo -auto
> 
> These tests pass for all other texture targets and the copyteximage one
> can even produce a GPU hang when we run the test for all texture targets
> (removing 1D_ARRAY from the parameter list) The hang goes away if I edit
> the test to remove 1D_ARRAY from the list of targets to test.

Actually, the GPU hang in copyteximage seems to exist in master without
any changes, it may need 2-3 runs, but eventually running
"bin/copyteximage -fbo -auto" will hang with current master.

> This is funny because the code seems to use use 2DArrays to some extent
> to implement 1DArrays and yet 2D arrays seem to work just fine. I am not
> familiar with the miptree setup code so if anyone has any clue about
> what could be happening here I would appreciate any hints I can get. I
> can also file a bug for this if that helps tracking this down.
> 
> This bug gets in the way of a fix for some dEQP tests that will require
> to recreate the miptrees to account for the actual miplevel count in
> some scenarios so I think that if we can't find the underlying problem
> here I might have to modify the patch to exclude 1DArrays from the fix
> to prevent this issue from popping up (although I think this is probably
> happening already if people use mipmap filters with 1darray textures
> that have more than one slice, but I suppose that is not a common use
> case).
> 
> Iago
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev