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

[Iago Toral]

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.

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