Bug 105704 - compiler assertion hit
Summary: compiler assertion hit
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-23 09:42 UTC by Tapani Pälli
Modified: 2018-03-27 21:15 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
shader test (752 bytes, text/plain)
2018-03-23 09:45 UTC, Tapani Pälli
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tapani Pälli 2018-03-23 09:42:11 UTC
I'm hitting following assert in compiler with the attached shader_test and bisected this to commit ee63933a73:

shader_runner: ../src/intel/compiler/brw_eu_emit.c:822: brw_alu3: Assertion `dest.file == BRW_GENERAL_REGISTER_FILE || dest.file == BRW_MESSAGE_REGISTER_FILE' failed.
Comment 1 Tapani Pälli 2018-03-23 09:45:34 UTC
Created attachment 138306 [details]
shader test

Attaching shader test. Original use-case was just vs+gs moving particles but I added here a fs so that issuing a draw will trigger the case.
Comment 2 Ian Romanick 2018-03-23 16:25:02 UTC
Does this only occur on HSW?  I was not able to reproduce the problem with this test case on my BDW.
Comment 3 Ian Romanick 2018-03-23 16:27:35 UTC
Interesting side note: This shader is hurt by 1 instruction by this optimization.
Comment 4 Tapani Pälli 2018-03-23 16:29:46 UTC
(In reply to Ian Romanick from comment #2)
> Does this only occur on HSW?  I was not able to reproduce the problem with
> this test case on my BDW.

Yes, sorry I did not remember to mention this but I tried also on KBL and could not reproduce it. So it is very likely HSW (+IVB?) specific. It could be that there is some 'hidden' issue we've found here.
Comment 5 Ian Romanick 2018-03-23 17:42:59 UTC
After this change, it seems that the backend is trying to emit something like

    mad.l.f0  null, ...

But 3 source instructions cannot write the null register.  Matt says fixup_3src_null_dest handles this for the fs backend.
Comment 6 Ian Romanick 2018-03-27 21:15:26 UTC
Fixed by:

commit 91225cb33f0baede872114bd416084b3b52937a1
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Fri Mar 23 11:46:12 2018 -0700

    i965/vec4: Fix null destination register in 3-source instructions
    
    A recent commit (see below) triggered some cases where conditional
    modifier propagation and dead code elimination would cause a MAD
    instruction like the following to be generated:
    
        mad.l.f0  null, ...
    
    Matt pointed out that fs_visitor::fixup_3src_null_dest() fixes cases
    like this in the scalar backend.  This commit basically ports that code
    to the vec4 backend.
    
    NOTE: I have sent a couple tests to the piglit list that reproduce this
    bug *without* the commit mentioned below.  This commit fixes those
    tests.
    
    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Tested-by: Tapani Pälli <tapani.palli@intel.com>
    Cc: mesa-stable@lists.freedesktop.org
    Fixes: ee63933a7 ("nir: Distribute binary operations with constants into bcsel")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105704


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.