Bug 76883 - brw_vec4_generator.cpp:184: compiler crash
Summary: brw_vec4_generator.cpp:184: compiler crash
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium major
Assignee: Tapani Pälli
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-01 07:04 UTC by Tapani Pälli
Modified: 2014-04-02 18:12 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
test case (1.46 KB, patch)
2014-04-01 07:05 UTC, Tapani Pälli
Details | Splinter Review
patch to fix the issue (2.64 KB, patch)
2014-04-02 05:48 UTC, Tapani Pälli
Details | Splinter Review
patch with a couple of clean ups (1.66 KB, patch)
2014-04-02 05:59 UTC, Matt Turner
Details | Splinter Review
final patch (2.70 KB, patch)
2014-04-02 06:17 UTC, Tapani Pälli
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Tapani Pälli 2014-04-01 07:04:27 UTC
Attached shader crashes on Sandybridge when Mesa is compiled with --enable-debug
Comment 1 Tapani Pälli 2014-04-01 07:05:48 UTC
Created attachment 96698 [details] [review]
test case

piglit test that exposes crash
Comment 2 Tapani Pälli 2014-04-01 07:23:10 UTC
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
Comment 3 Tapani Pälli 2014-04-01 07:24:34 UTC
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.
Comment 4 Matt Turner 2014-04-01 22:11:49 UTC
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?
Comment 5 Tapani Pälli 2014-04-02 03:35:09 UTC
(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.
Comment 6 Tapani Pälli 2014-04-02 05:48:06 UTC
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.
Comment 7 Matt Turner 2014-04-02 05:59:05 UTC
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. :)
Comment 8 Tapani Pälli 2014-04-02 06:17:31 UTC
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!
Comment 9 Tapani Pälli 2014-04-02 18:12:11 UTC
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.