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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
