You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ran into an interesting case with a emulator shader translator where it was outputting a shader that branches over its whole logic to a OpDemoteToHelperInvocation at the end.
When translated to MSL, the shader results in a main function with the following structure:
fragment main0_out main0(main0_in in [[stage_in]], ...)
{
main0_out out = {};
...
if (false)
{
...
return out;
}
discard_fragment();
}
This results in the following MSL compile error:
program_source:1199:1: error: control reaches end of non-void fragment function [-Werror,-Wmtl-shader-return-type]
}
^
Now, I am not sure whether this is actually how the shader was supposed to be translated from its original assembly to SPIR-V. I've looked into this further and the shader does in fact just block its logic behind an always-false condition and discard. I do believe the resulting SPIR-V is a valid shader with no errors from spirv-val, so I think cases like this where a shader discards unconditionally should produce valid MSL shaders. I believe adding a dummy return after the discard can fix the issue, see another case of this for reference: gfx-rs/wgpu#4458
The text was updated successfully, but these errors were encountered:
Ran into an interesting case with a emulator shader translator where it was outputting a shader that branches over its whole logic to a
OpDemoteToHelperInvocation
at the end.The SPIR-V at the end looks like this:
When translated to MSL, the shader results in a main function with the following structure:
This results in the following MSL compile error:
Now, I am not sure whether this is actually how the shader was supposed to be translated from its original assembly to SPIR-V.I've looked into this further and the shader does in fact just block its logic behind an always-false condition and discard. I do believe the resulting SPIR-V is a valid shader with no errors fromspirv-val
, so I think cases like this where a shader discards unconditionally should produce valid MSL shaders. I believe adding a dummy return after the discard can fix the issue, see another case of this for reference: gfx-rs/wgpu#4458The text was updated successfully, but these errors were encountered: