Bug 111071

Summary: SPIR-V shader processing fails with message about "extra dangling SSA sources"
Product: Mesa Reporter: Alastair Donaldson <afdx>
Component: Drivers/Vulkan/intelAssignee: Intel 3D Bugs Mailing List <intel-3d-bugs>
Status: RESOLVED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium CC: jason
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Amber test exposing the problem
bactrace
Rectified test

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:
0x561df6f9fb88
0x561df6f9ff48
0x561df6f9f7c8
0x561df6fa0308
Aborted

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]
bactrace

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:
  /home/den/Downloads/nested-ifs-and-return-in-for-loop.amber

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
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1312

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.