Bug 111071 - SPIR-V shader processing fails with message about "extra dangling SSA sources"
Summary: SPIR-V shader processing fails with message about "extra dangling SSA sources"
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2019-07-04 23:01 UTC by Alastair Donaldson
Modified: 2019-07-15 20:00 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Amber test exposing the problem (4.52 KB, text/plain)
2019-07-04 23:01 UTC, Alastair Donaldson
bactrace (6.08 KB, text/plain)
2019-07-05 08:04 UTC, Denis
Rectified test (4.52 KB, text/plain)
2019-07-10 22:57 UTC, Alastair Donaldson

Description Alastair Donaldson 2019-07-04 23:01:05 UTC
Created attachment 144707 [details]
Amber test exposing the problem

Running the attached test using Amber (https://github.com/google/amber):

amber nested-ifs-and-return-in-for-loop.amber

should lead to the test passing.

Instead, Amber crashes and the following is emitted:

extra dangling SSA sources:

It looks like this message comes from src/compiler/nir/nir_validate.c.

Build: Mesa 19.2.0-devel (git-243db4980c) (Debug)
Device: Intel(R) HD Graphics 630 (Kaby Lake GT2)

Interestingly, using Mesa 18.0.3, the test does not crash, but fails due to an incorrect colour being probed from the image that is rendered.
Comment 1 Denis 2019-07-05 08:04:27 UTC
Created attachment 144710 [details]

added backtrace from 
Mesa 19.2.0-devel (git-0cc02c9ea6)

and confirming the fail on earlier mesa (18.0.0)

[den@den-pc Debug]$ ./amber ~/Downloads/nested-ifs-and-return-in-for-loop.amber 
/home/den/Downloads/nested-ifs-and-return-in-for-loop.amber: Line 159: Probe failed at: 0, 0
  Expected RGBA: 255.000000, 0.000000, 0.000000, 255.000000
  Actual RGBA: 255.000000, 255.000000, 255.000000, 255.000000
Probe failed in 1 pixels

Summary of Failures:

Summary: 0 pass, 1 fail
Comment 2 Sergii Romantsov 2019-07-05 14:46:28 UTC
will try to look on that
Comment 3 Jason Ekstrand 2019-07-10 20:18:08 UTC

That fixes the validation fail and gets us back to rendering the wrong color.  Haven't debugged that issue yet.
Comment 4 Jason Ekstrand 2019-07-10 22:25:21 UTC
Also, are you sure that test is correct?  It's doing

> void main()
> {
>  _GLF_color = vec4(1.0, 0.0, 0.0, 1.0);
>  for(
>      int i = 0;
>      i < 10;
>      i ++
>  )
>   {
>    _GLF_color = vec4(1.0);
>    if(1.0 > injectionSwitch.y)
>     {
>      _GLF_color = vec4(1.0, 0.0, 0.0, 1.0);
>      if(true)
>       {
>        return;
>       }
>     }
>   }
> }

but the input data it sets up has injectionSwitch.y == 1.0 so the if will fail because 1.0 > 1.0 is false and so _GLF_color will get overwritten to vec4(1.0) and never written back to red.  Our compiler seems to be compiling it correctly.
Comment 5 Alastair Donaldson 2019-07-10 22:57:05 UTC
Created attachment 144756 [details]
Rectified test

Thanks for fixing the validation issue, Jason.

My bad regarding the probe in the test - I overlooked that write of vec4(1.0) when writing the probe.

You are correct that white should indeed be rendered.  The attached test case exposes the original bug (the error), and this time really should pass (and indeed does pass on my Mesa 18.0.5 driver).
Comment 6 Jason Ekstrand 2019-07-15 20:00:15 UTC
Fixed by the following commit now in master:

commit 7a19e05e8c84152af3a15868f5ef781142ac8e23
Author: Jason Ekstrand <jason@jlekstrand.net>
Date:   Wed Jul 10 15:14:42 2019 -0500

    nir/opt_if: Clean up single-src phis in opt_if_loop_terminator
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111071
    Fixes: 2a74296f24ba "nir: add opt_if_loop_terminator()"
    Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

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.