| Summary: | [Debug mesa only]. Crash happens when calling drawArrays | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | xinghua <xinghua.cao> |
| Component: | Drivers/DRI/i965 | Assignee: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | yang.gu, yunchao.he |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | simple reproduccer to simplify the debugging process. | ||
|
Description
xinghua
2018-09-19 08:16:56 UTC
xinghua, it would help if you could bisect this issue. Let us know if you cannot. Hi. It doesn't reproduce on system drivers because they were built without "debug" flags. Reproduced this issue on debug mesa versions: 18.3.0-git 18.2.1 (tag) 18.0.0 (tag) 17.3.6 (tag) Also I found interesting behavior. Even on latest mesa, after running test several times - 3-5, it will pass and crashes will disappear. I thought that it might be some cashed data, but cache is empty for the page. The same behavior and for test from this bug https://bugs.freedesktop.org/show_bug.cgi?id=107892 (In reply to Mark Janes from comment #1) > xinghua, it would help if you could bisect this issue. Let us know if you > cannot. Hi, Mark, We will try to bisect it. This test is relatively new (from last year) so it could be that the bug has been always there. It seems that test first uploads a texture with size 2x2, then it changes base level to 2 and uploads level 0 again with different size 1x1. For some reason we then fail extents checking in 'intel_miptree_match_image'. It could be because of the base level change. (In reply to Tapani Pälli from comment #4) > This test is relatively new (from last year) so it could be that the bug has > been always there. It seems that test first uploads a texture with size 2x2, > then it changes base level to 2 and uploads level 0 again with different > size 1x1. For some reason we then fail extents checking in > 'intel_miptree_match_image'. It could be because of the base level change. Hi, Tapani, It seems that you had known the root cause of this issue. Do you still need me to bisect it for you? (In reply to xinghua from comment #5) > (In reply to Tapani Pälli from comment #4) > > This test is relatively new (from last year) so it could be that the bug has > > been always there. It seems that test first uploads a texture with size 2x2, > > then it changes base level to 2 and uploads level 0 again with different > > size 1x1. For some reason we then fail extents checking in > > 'intel_miptree_match_image'. It could be because of the base level change. > > Hi, Tapani, > It seems that you had known the root cause of this issue. Do you still need > me to bisect it for you? My feeling is that this is not a regression but we've always had it. It seems like some other drivers had it as well: https://bugs.chromium.org/p/chromium/issues/detail?id=705865&desc=4 (In reply to Tapani Pälli from comment #6) > (In reply to xinghua from comment #5) > > (In reply to Tapani Pälli from comment #4) > > > This test is relatively new (from last year) so it could be that the bug has > > > been always there. It seems that test first uploads a texture with size 2x2, > > > then it changes base level to 2 and uploads level 0 again with different > > > size 1x1. For some reason we then fail extents checking in > > > 'intel_miptree_match_image'. It could be because of the base level change. > > > > Hi, Tapani, > > It seems that you had known the root cause of this issue. Do you still need > > me to bisect it for you? > > My feeling is that this is not a regression but we've always had it. It > seems like some other drivers had it as well: > > https://bugs.chromium.org/p/chromium/issues/detail?id=705865&desc=4 Did you already dive into this issue? Just to avoid collision with you if yes :-) Created attachment 141837 [details] simple reproduccer to simplify the debugging process. Hi, I have created the simple reproducer because debugging the chrome not very convenient. My current progress in this issue: I managed to reproduce this issue in the following way: 1. Use shader program which is used at least one 'texture sample' in FS instead of 'FF'. 2. Setup following property for texture GL_TEXTURE_MIN_FILTER = GL_LINEAR or GL_NEAREST 3. The program must upload level 2 = 4x4, 1 = 2x2, 0 = 1x1. The pixels values is not matter but must be uploaded and sequence of uploading is very matter, firstly level 2 then 1 and lastly 0. 4. The last operation which should cause the assertion is glDrawArrays which uses shader and texture mentioned above to draw some rectangle. I found out that when we try to re-create miptree in 'intel_finalize_mipmap_tree' function we don't consider the 'base level' in width0, height0, depth0 calculations. I not very familiar with this part of the mesa code but I found that the 'intel_miptree_create_for_teximage' function consider the 'base level'. So I tried to do it in 'intel_finalize_mipmap_tree' and that fixes this issue for me. So I hope that this is a possible fix: https://patchwork.freedesktop.org/patch/254397/ (In reply to asimiklit from comment #8) > Created attachment 141837 [details] > simple reproduccer to simplify the debugging process. > > Hi, > > I have created the simple reproducer because debugging the chrome not very > convenient. > > My current progress in this issue: > > I managed to reproduce this issue in the following way: > 1. Use shader program which is used at least one 'texture sample' in FS > instead of 'FF'. > 2. Setup following property for texture GL_TEXTURE_MIN_FILTER = GL_LINEAR or > GL_NEAREST > 3. The program must upload level 2 = 4x4, 1 = 2x2, 0 = 1x1. The pixels > values is not matter but must be uploaded and sequence of uploading is very > matter, firstly level 2 then 1 and lastly 0. > 4. The last operation which should cause the assertion is glDrawArrays which > uses shader and texture mentioned above to draw some rectangle. > > I found out that when we try to re-create miptree in > 'intel_finalize_mipmap_tree' function we don't consider the 'base level' in > width0, height0, depth0 calculations. > I not very familiar with this part of the mesa code but I found that the > 'intel_miptree_create_for_teximage' function consider the 'base level'. > So I tried to do it in 'intel_finalize_mipmap_tree' and that fixes this > issue for me. So I hope that this is a possible fix: > https://patchwork.freedesktop.org/patch/254397/ *wording fix* 1. Use shader program which uses at least one 'texture sample' in FS instead of 'FF'. I a piglit test was suggested to avoid regressions in future: https://patchwork.freedesktop.org/patch/257925 I tried latest Ubuntu 19.04 (Mesa 19.0.1), and the issue can't be reproduced. Thanks for the fix! *** Bug 111083 has been marked as a duplicate of this bug. *** |
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.