Summary: | brw_fs_schedule_instructions.cpp segfault due to accessing not allocated last_mrf_write[16] | ||
---|---|---|---|
Product: | Mesa | Reporter: | youonly@mailinator.com <youonly> |
Component: | Drivers/DRI/i965 | Assignee: | Kenneth Graunke <kenneth> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | eric, idr |
Version: | 8.0 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
youonly@mailinator.com
2012-04-02 15:19:04 UTC
Could you please send us the output of: glxinfo | grep renderer (I'm guessing you're using Sandybridge, but it'd be nice to double check.) Thanks! OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile x86/MMX/SSE2 this is lenovo laptop updating to kernel 3.3.1 do not solve this issue. only patched version of brw_fs_schedule_instructions.cpp allows to run gzdoom Sorry for not getting to this sooner... The bug is that we were creating a message that tried to use m2..m16, when there technically is no m16 register on the hardware. This caused us to make an out-of-bounds address during instruction scheduling, and thus crash. However, simply making the array bigger is not a good solution, since it still means we'd try to use a non-existent register. According to the documentation, it -may- wrap around and use m0, but that's not guaranteed and we're told not to rely on it. Instead, I changed it to use m1..m15. Mesa patches to fix the bug: http://lists.freedesktop.org/archives/mesa-dev/2012-April/021113.html http://lists.freedesktop.org/archives/mesa-dev/2012-April/021114.html Piglit test: http://lists.freedesktop.org/archives/piglit/2012-April/002251.html Assuming it passes the review, I'll commit these soon. Thanks again for the report! Fixed on Mesa master by: commit b443ca96a55a06ee215a3f9a9e7dba558deeb58c Author: Kenneth Graunke <kenneth@whitecape.org> Date: Tue Apr 24 14:09:13 2012 -0700 i965/fs: Fix FB writes that tried to use the non-existent m16 register. A little analysis shows that the worst-case value for "nr" is 17: - base_mrf = 2 ... 2 - header present (say gen == 5) ... 4 - aa_dest_stencil_reg (stencil test) ... 5 - SIMD16 mode: += 4 * reg_width ... 13 - source_depth_to_render_target ... 15 - dest_depth_reg ... 17 This resulted in us setting base_mrf to 2 and mlen to 15. In other words, we'd try to use m2..m16. But m16 doesn't exist pre-Gen6. Also, the instruction scheduler data structures use arrays of size 16, so this would cause us to access them out of bounds. While the debugger system routine may need m0 and m1, we don't use it today, so the simplest solution is just to move base_mrf back to 1. That way, our worst case message fits in m1..m15, which is legal. An alternative would be to fail on SIMD16 in this case, but that seems a bit unfortunate if there's no real need to reserve m0 and m1. Fixes new piglit test shaders/depth-test-and-write on Ironlake. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48218 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> which I also cherry-picked to the 8.0 branch as commit bcc5caf642a9beec324657becac501944ce4dc23. |
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.