[spv-out] Add multiply instructions

[Timo-DK]

Add support for the long-awaited multiply instructions:

• OpIMul
• OpFMul
• OpVectorTimesScalar
• OpVectorTimesMatrix
• OpMatrixTimesVector
• OpMatrixTimesScalar
• OpMatrixTimesMatrix

Tested with the following WGSL:

[[stage(fragment)]]
fn main() -> void {
    # OpIMul
    var int_1: i32 = 1;
    var int_2: i32 = int_1 * int_1;

    # OpFMul
    var float_1: f32 = 1.0;
    var float_2: f32 = float_1 * float_1;

    # OpVectorTimesScalar
    var vec_1: vec2<f32> = vec2<f32>(1.0, 1.0);
    var vec_2: vec2<f32> = vec_1 * float_1;

    # OpVectorTimesMatrix
    var mat_1: mat2x2<f32> = mat2x2<f32>(1.0, 1.0);
    var vec_3: vec2<f32> = vec_2 * mat_1;

    # OpMatrixTimesVector
    var vec_4: vec2<f32> = mat_1 * vec_3;

    # OpMatrixTimesScalar
    var mat_2: mat2x2<f32> = mat_1 * float_2;

    # OpMatrixTimesMatrix
    var mat_3: mat2x2<f32> = mat_2 * mat_2;

    return;
}

[kvark]

why are there load instructions here?

[Timo-DK]

That is, because the values are from an OpVariable for instance, and to use an OpVariable, you have to load them through OpLoad.

[kvark]

hmm, but there isn't any check here about whether the target is OpVariable or not. So how do we know that unconditionally "load"-ing is the right thing to do?

[Timo-DK]

That is true, but as far as I know there are only two ways to use binary instructions at high level: via pointers, and via constants.

I have done some research at http://shader-playground.timjones.io/, and when doing it via pointers, there is always an OpLoad needed.

GLSL:

void main()
{
    vec2 vec_1 = vec2(1.0, 1.0);
    float float_1 = vec_1.x * vec_1.y;
    float float_3 = float_1 * float_1;
}

This will always translate back to OpLoad, whether it is via an OpAccessChain or OpVariable. There probably are more ways of accessing value via pointers, but all pointers always need to be loaded in via OpLoad to be useful (as far as I know).

What is good to see, is that when I am using constants, instead of variables at the shader playground, it pre-calculates the value, and uses it directly (which is allowed).

GLSL:

void main()
{
    float float_1 = 1.0 * 2.0;
}

However, because of the pre-calculation, the resulting SPIR-V output does not even contain a binary instruction, as it is already calculated.

I think it is safe to say for now to always use OpLoad here, but maybe you think about a case where this might not be, please let me know, so we can reconsider this piece of code.

[kvark]

We can't always use OpLoad there. It should only happen if the target expression is a variable. Once it's a different expression, there should be no load. For example, if you do float x = 2 * (y + 1);

[Timo-DK]

Ah yes, I understand what you mean. I have a rough idea, and will try to implement it tomorrow: what if we never check for the specific Expression::LocalVariable, but let the match arm of Expression::LocalVariable always create and return an OpLoad?

That should fix this issue, and the rest of the code will be cleaner, as Expression::Return, and Expression::Store have a specific match for if the id of the expression is of the expression type Expression::LocalVariable. This is pretty dirty to be honest, but I didn't see that back then.

[kvark]

yes, both LocalVariable and GlobalVariable variants need to generate OpLoad.

[Timo-DK]

Fixed and now it supports even "unlimited" expression nesting:

var float_1: f32 = 2.0 * (2.0 * (4.0 * 2.0));

Giving the predicted result without an OpLoad, like you said (and correctly validates):

%5 = OpVariable %_ptr_Function_float Function
%13 = OpFMul %float %float_4 %float_2
%12 = OpFMul %float %float_2 %13
%11 = OpFMul %float %float_2 %12
      OpStore %5 %11 None

[kvark]

Just one concern

[kvark]

hmm, but there isn't any check here about whether the target is OpVariable or not. So how do we know that unconditionally "load"-ing is the right thing to do?