On Wed, 2015-01-28 at 13:39 +0100, Iago Toral wrote: > 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.
I can't reproduce it like this in IvyBridge though. For this to happen there I have to force the mipmap to be re-created in intel_finalize_mipmap_tree as I originally described. > > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
