Attached shader crashes on Sandybridge when Mesa is compiled with --enable-debug
Created attachment 96698 [details] [review] test case piglit test that exposes crash
Program received signal SIGABRT, Aborted. 0x00000033e98359e9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing separate debuginfos, use: debuginfo-install dbus-libs-1.6.12-2.fc19.x86_64 expat-2.1.0-5.fc19.x86_64 freetype-2.4.11-7.fc19.x86_64 libX11-1.6.0-1.fc19.x86_64 libXScrnSaver-1.2.2-5.fc19.x86_64 libXau-1.0.8-1.fc19.x86_64 libXcursor-1.1.14-1.fc19.x86_64 libXdamage-1.1.4-3.fc19.x86_64 libXext-1.3.2-1.fc19.x86_64 libXfixes-5.0.1-1.fc19.x86_64 libXi-1.7.2-1.fc19.x86_64 libXinerama-1.1.3-1.fc19.x86_64 libXrandr-1.4.1-1.fc19.x86_64 libXrender-0.9.7-6.20130524git786f78fd8.fc19.x86_64 libXxf86vm-1.1.3-1.fc19.x86_64 libgcc-4.8.2-7.fc19.x86_64 libjpeg-turbo-1.2.90-3.fc19.x86_64 libpciaccess-0.13.1-3.fc19.x86_64 libstdc++-4.8.2-7.fc19.x86_64 libxcb-1.9-3.fc19.x86_64 systemd-libs-204-18.fc19.x86_64 zlib-1.2.7-10.fc19.x86_64 (gdb) bt #0 0x00000033e98359e9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00000033e98370f8 in __GI_abort () at abort.c:90 #2 0x00000033e982e956 in __assert_fail_base (fmt=0x33e997ddc8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7ffff692f6bc "dst.dw1.bits.writemask == 0xf", file=file@entry=0x7ffff692f5b4 "brw_vec4_generator.cpp", line=line@entry=184, function=function@entry=0x7ffff692fee0 <brw::vec4_generator::generate_math1_gen6(brw::vec4_instruction*, brw_reg, brw_reg)::__PRETTY_FUNCTION__> "void brw::vec4_generator::generate_math1_gen6(brw::vec4_instruction*, brw_reg, brw_reg)") at assert.c:92 #3 0x00000033e982ea02 in __GI___assert_fail (assertion=0x7ffff692f6bc "dst.dw1.bits.writemask == 0xf", file=0x7ffff692f5b4 "brw_vec4_generator.cpp", line=184, function=0x7ffff692fee0 <brw::vec4_generator::generate_math1_gen6(brw::vec4_instruction*, brw_reg, brw_reg)::__PRETTY_FUNCTION__> "void brw::vec4_generator::generate_math1_gen6(brw::vec4_instruction*, brw_reg, brw_reg)") at assert.c:101 #4 0x00007ffff6830441 in brw::vec4_generator::generate_math1_gen6 (this=0x7fffffffc710, inst=0x1ef6100, dst=..., src=...) at brw_vec4_generator.cpp:184 #5 0x00007ffff6832b34 in brw::vec4_generator::generate_vec4_instruction (this=0x7fffffffc710, instruction=0x1ef6100, dst=..., src=0x7fffffffc620) at brw_vec4_generator.cpp:1152 #6 0x00007ffff6833259 in brw::vec4_generator::generate_code (this=0x7fffffffc710, instructions=0x7fffffffc7f0) at brw_vec4_generator.cpp:1323 #7 0x00007ffff6833448 in brw::vec4_generator::generate_assembly (this=0x7fffffffc710, instructions=0x7fffffffc7f0, assembly_size=0x7fffffffd7d4) at brw_vec4_generator.cpp:1367 #8 0x00007ffff682e1e5 in brw_vs_emit (brw=0x8684c0, prog=0x1ef1610, c=0x7fffffffd720, prog_data=0x7fffffffd630, mem_ctx=0x1e88e40, final_assembly_size=0x7fffffffd7d4) at brw_vec4.cpp:1817 #9 0x00007ffff685fe14 in do_vs_prog (brw=0x8684c0, prog=0x1ef1610, vp=0x1eefa20, key=0x7fffffffd830) at brw_vs.c:293 #10 0x00007ffff6860ad2 in brw_vs_precompile (ctx=0x8684c0, prog=0x1ef1610) at brw_vs.c:542 #11 0x00007ffff6821340 in brw_shader_precompile (ctx=0x8684c0, prog=0x1ef1610) at brw_shader.cpp:78 #12 0x00007ffff6821b29 in brw_link_shader (ctx=0x8684c0, shProg=0x1ef1610) at brw_shader.cpp:275 #13 0x00007ffff668df05 in _mesa_glsl_link_shader (ctx=0x8684c0, prog=0x1ef1610) at program/ir_to_mesa.cpp:3093 #14 0x00007ffff6535dfd in link_program (ctx=0x8684c0, program=9) at main/shaderapi.c:918 #15 0x00007ffff6536c40 in _mesa_LinkProgram (programObj=9) at main/shaderapi.c:1386
bisected to ----------- 8< -------------- commit dc0f5099fa3cb564c25eb892fde93cacd29df8f1 Author: Matt Turner <mattst88@gmail.com> Date: Tue Mar 11 13:06:20 2014 -0700 i965/vec4: Track live ranges per-channel, not per vgrf. Will be squashed with the next patch.
Huh. I'm not able to reproduce. The bisected commit isn't really useful, because I meant to squash it into the next patch, as the commit message says. Can you reproduce the crash using the next commit, 9630ba6c or better yet, master?
(In reply to comment #4) > Huh. I'm not able to reproduce. The bisected commit isn't really useful, > because I meant to squash it into the next patch, as the commit message > says. Can you reproduce the crash using the next commit, 9630ba6c or better > yet, master? Yep this is just a 'raw bisect', bug can be reproduced with master. Note that you need Sandybridge to reproduce as the assert happens only with gen == 6. I believe SNB needs all the swizzle channels for some particular math operation but the new optimizations changes masks so that it is not a full mask. I can try today if I can tackle this with a patch that bypasses mask modifications in case we are on SNB.
Created attachment 96756 [details] [review] patch to fix the issue This patch fixes the issues for me. To be honest I'm not sure if all the math operations require writemask to be XYZW but it seems many of them do.
Created attachment 96757 [details] [review] patch with a couple of clean ups We're already disallowing trimming the writemask from tex instructions, so it's natural to just use the same if statement for gen6/math. Give that a test and send it to the list with your authorship. Thanks a bunch for tracking this down. :)
Created attachment 96760 [details] [review] final patch heh, I also did the is_math() cleanup, here's my patch with your cleanup changes, I'll send this to the list!
patch is in, resolving as fixed
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.