[naga const-eval] LiteralVector and some demo builtins

[sagudev]

Connections
Implements some #4507

Description
Existing macros work for component-wise cases where return type is equal to input type. But it's hard to generalize macros further. So I present LiteralVector:

/// Vector for each [`Literal`] type
///
/// This type ensures that all elements have same type
enum LiteralVector {
    F64(ArrayVec<f64, { crate::VectorSize::MAX }>),
    F32(ArrayVec<f32, { crate::VectorSize::MAX }>),
    U32(ArrayVec<u32, { crate::VectorSize::MAX }>),
    I32(ArrayVec<i32, { crate::VectorSize::MAX }>),
    U64(ArrayVec<u64, { crate::VectorSize::MAX }>),
    I64(ArrayVec<i64, { crate::VectorSize::MAX }>),
    Bool(ArrayVec<bool, { crate::VectorSize::MAX }>),
    AbstractInt(ArrayVec<i64, { crate::VectorSize::MAX }>),
    AbstractFloat(ArrayVec<f64, { crate::VectorSize::MAX }>),
}

that abstracts away at least vector obtaining logic. This makes somehow easier to implement some builtins like dot, cross, any, all, ... although with still way to much repetition (maybe macro could fix that, although I am more inclined to use num create for number traits).

Testing
TODO

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[sagudev]

Any thought @teoxoy @ErichDonGubler ?

[ErichDonGubler]

Hoo boy. This looks really involved, and I definitely haven't yet taken the time to dig into everything. I'm not sure if I'll be able to prioritize this within the week, but I will say this: Something that allows more PASSes in a CTS context would be pretty compelling, even if not completely correct. Do you have any new PASSes in Servo CTS runs? 😀

[sagudev]

Do you have any new PASSes in Servo CTS runs? 😀

I do not have CTS results yet, as I didn't handle all necessary types in dot,cross yet.

Something that allows more PASSes in a CTS context would be pretty compelling, even if not completely correct.

Actually this should be correct per spec, just not optimal performance wise (due to redundant checking).

[sagudev]

bad_cross_builtin_args fails because we start const evaluating init expr before we mark it as non-const:

wgpu/naga/src/front/wgsl/lower/mod.rs

Line 1369 in 0e352f5

self.expression(l.init, &mut ctx.as_expression(block, &mut emitter))?;

[sagudev]

results from [servo's CTS run:](https://github.com/sagudev/servo/actions/runs/10859244967)

OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,all:argument_types:*
    PASS [expected FAIL] subtest: :type="vec2%3Cbool%3E"
    PASS [expected FAIL] subtest: :type="vec3%3Cbool%3E"
    PASS [expected FAIL] subtest: :type="vec4%3Cbool%3E"
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,all:arguments:*
    PASS [expected FAIL] subtest: :test="i32"
    PASS [expected FAIL] subtest: :test="u32"
    PASS [expected FAIL] subtest: :test="f32"
    PASS [expected FAIL] subtest: :test="vec_i32"
    PASS [expected FAIL] subtest: :test="vec_u32"
    PASS [expected FAIL] subtest: :test="vec_f32"
    PASS [expected FAIL] subtest: :test="matrix"
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,any:argument_types:*
    PASS [expected FAIL] subtest: :type="vec2%3Cbool%3E"
    PASS [expected FAIL] subtest: :type="vec3%3Cbool%3E"
    PASS [expected FAIL] subtest: :type="vec4%3Cbool%3E"
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,any:arguments:*
    PASS [expected FAIL] subtest: :test="i32"
    PASS [expected FAIL] subtest: :test="u32"
    PASS [expected FAIL] subtest: :test="f32"
    PASS [expected FAIL] subtest: :test="vec_i32"
    PASS [expected FAIL] subtest: :test="vec_u32"
    PASS [expected FAIL] subtest: :test="vec_f32"
    PASS [expected FAIL] subtest: :test="matrix"
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,cross:must_use:*
    FAIL [expected PASS] subtest: :use=true
        VALIDATION FAILED: Unexpected compilationInfo 'error' message.
        1:14: error: 
        Shader '' parsing error: Cannot apply math function to type
           ┌─ wgsl:1:14
           │
         1 │ fn f() { _ = cross(vec3(0), vec3(1)); }
           │              ^^^^^ see msg
    PASS [expected FAIL] subtest: :use=false
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,cross:values:*
    PASS [expected FAIL] subtest: :stage="constant";type="vec3%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="override";type="vec3%3Cf32%3E"
OK /_webgpu/webgpu/cts.https.html?
    FAIL [expected PASS] subtest: :use=true 
        VALIDATION FAILED: Unexpected compilationInfo 'error' message.
        1:14: error: 
        Shader '' parsing error: Cannot apply math function to type
           ┌─ wgsl:1:14
           │
         1 │ fn f() { _ = distance(vec3(0), vec3(1)); }
           │              ^^^^^^^^ see msg
    PASS [expected FAIL] subtest: :use=false
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,distance:values:*
    PASS [expected FAIL] subtest: :stage="constant";type="vec2%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="constant";type="vec3%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="constant";type="vec4%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="override";type="vec2%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="override";type="vec3%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="override";type="vec4%3Cf32%3E"
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,dot:args:*
    PASS [expected FAIL] subtest: :arg="good"
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,dot:values:*
    PASS [expected FAIL] subtest: :stage="constant";type="vec3%3Cabstract-int%3E"
    PASS [expected FAIL] subtest: :stage="constant";type="vec4%3Cabstract-int%3E"
    PASS [expected FAIL] subtest: :stage="constant";type="vec2%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="constant";type="vec3%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="constant";type="vec4%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="override";type="vec2%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="override";type="vec3%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="override";type="vec4%3Cf32%3E"
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,length:args:*
    PASS [expected FAIL] subtest: :arg="good"
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,length:integer_argument:*
    PASS [expected FAIL] subtest: :type="f32"
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,length:vec2:*
    PASS [expected FAIL] subtest: :stage="constant";type="vec2%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="override";type="vec2%3Cf32%3E"
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,length:vec3:*
    PASS [expected FAIL] subtest: :stage="constant";type="vec3%3Cf32%3E"
    PASS [expected FAIL] subtest: :stage="override";type="vec3%3Cf32%3E"
OK [expected TIMEOUT] /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,call,builtin,length:vec4:*
    FAIL [expected PASS] subtest: :stage="constant";type="vec4%3Cabstract-int%3E" 
         VALIDATION FAILED: subcase: x="-9223372036854775808n";y="-9223372036854775808n";z="-9223372036854775808n";w="-9223372036854775808n"
        Unexpected compilationInfo 'error' message.
        2:19: error: 
        Shader '' parsing error: failed to convert expression to a concrete type: the concrete type i32 cannot represent the abstract value -9223372036854775808 accurately
        ┌─ wgsl:2:19
        │
      2 │ const v  = length(vec4((-9223372036854775807 - 1), (-9223372036854775807 - 1), (-9223372036854775807 - 1), (-9223372036854775807 - 1)));
        │                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this expression has type vec4<{AbstractInt}>
        │
        = note: the expression should have been converted to have i32 scalar type
    ...
OK /_webgpu/webgpu/cts.https.html?q=webgpu:shader,validation,expression,overload_resolution:implicit_conversions:*
    PASS [expected FAIL] subtest: :case="vector_absint_to_u32"
    PASS [expected FAIL] subtest: :case="vector_absint_to_i32"
    PASS [expected FAIL] subtest: :case="vector_absint_to_f32"
    PASS [expected FAIL] subtest: :case="vector_absfloat_to_f32"
    PASS [expected FAIL] subtest: :case="vector_abstract_to_integer"
    PASS [expected FAIL] subtest: :case="mat2x2_index_absint"
    PASS [expected FAIL] subtest: :case="mat2x2_index_absfloat"
    PASS [expected FAIL] subtest: :case="mat2x2_index_float"

[sagudev]

Cannot apply math function to type error is because WGSL specs says that cross only accepts floats, so we would probably need to do automatic conversions here (AbstractInt -> AbstractFloat).

[sagudev]

gentle ping @ErichDonGubler

SIDE-NOTE: One thing that is annoying is that we do validation in validator and here in const eval (although most error cases should be unreachable here due to validator).

[ErichDonGubler]

Hey @sagudev! I actually was assuming that you'd bring this PR out of draft before I should review it. The new PASSes from your Servo test run are exciting. I didn't notice any regressions, but wanted to confirm: are there any? If there are no regressions, I don't see a reason why we shouldn't review this immediately, and iterate on this code further for readability, etc.

[ErichDonGubler]

thought: The large matches generated for LiteralVector seem like they could be better served with a macro_rules! macro to generate code; I think it'd be easier to read (i.e., see the patterns, since they're explicit) and modify code down the line.

[sagudev]

Macros are hard. Here is a prototype I wrote during weekend: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=846b65db0f424adf84653355c32815a4 (there are many macros limitations that were limiting me such as that macros must only return expr not patterns and repetition nesting rules).

[sagudev]

TBH I am not really happy how macro turned out in 21acc9d

What do you think @ErichDonGubler?

[sagudev]

I actually was assuming that you'd bring this PR out of draft before I should review it

I first wanted to get green light for idea/concept. I keep my PRs as draft until they are actually ready to land (at least from my side), to prevent accidental lands.

I didn't notice any regressions, but wanted to confirm: are there any?

No there aren't any (at least in old run).

[sagudev]

rebased!