Improve the calculation of location sizes for arrays and structs (revives #513)

[expenses]

See PR #513 that @Arc-blroth opened.

This PR builds on top of that to support structs and 3 or 4 component 64-bit scalar type vectors (see #513 (review)).

[expenses]

I haven't been able to test this with matrices yet as rust-gpu treats the glam Mat3s etc. as structs.

[expenses]

So I still get validation and perf warning for the specific use case I wanted this for, but I can't do anything about that :P

UNASSIGNED-CoreValidation-Shader-InterfaceTypeMismatch(ERROR / SPEC): msgNum: -1227934722 - Validation Error: [ UNASSIGNED-CoreValidation-Shader-InterfaceTypeMismatch ] Object 0: handle = 0xead9370000000008, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0xb6cf33fe | Attribute type of 'VK_FORMAT_R32G32B32_SFLOAT' at location 5 does not match vertex shader input type of 'ptr to input struct of (struct of (vec3 of float32, vec3 of float32, vec3 of float32))' Objects: 1 [0] 0xead9370000000008, type: 15, name: NULL

UNASSIGNED-CoreValidation-Shader-OutputNotConsumed(WARN / PERF): msgNum: 101294395 - Validation Performance Warning: [ UNASSIGNED-CoreValidation-Shader-OutputNotConsumed ] Object 0: handle = 0xead9370000000008, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x609a13b | Vertex attribute at location 6 not consumed by vertex shader Objects: 1 [0] 0xead9370000000008, type: 15, name: NULL

UNASSIGNED-CoreValidation-Shader-OutputNotConsumed(WARN / PERF): msgNum: 101294395 - Validation Performance Warning: [ UNASSIGNED-CoreValidation-Shader-OutputNotConsumed ] Object 0: handle = 0xead9370000000008, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x609a13b | Vertex attribute at location 7 not consumed by vertex shader Objects: 1 [0] 0xead9370000000008, type: 15, name: NULL

[eddyb]

LGTM modulo the name of the new method.

[eddyb]

Can this be renamed to location_count_of_type or location_slots_per_type? "size_of" could get confused with the size in bytes, which AFAICT is not relevant here.

[khyperia]

What's up with this rewrite rule? It seems like it's probably hiding a bug that should be fixed.

[expenses]

This is here because the ordering of the OpMemberNames gets altered between runs:

running 1 test
diff of stderr:

 OpCapability Float64
 OpCapability Int16
 OpCapability Int64
 OpCapability Int8
 OpCapability ShaderClockKHR
 OpCapability Shader
 OpExtension "SPV_KHR_shader_clock"
 OpMemoryModel Logical Simple
 OpEntryPoint Fragment %1 "main" %2 %3 %4 %5 %6 %7 %8 %9
 OpExecutionMode %1 OriginUpperLeft
 %10 = OpString "$OPSTRING_FILENAME/array_location_calculation.rs"
 OpMemberName %11 0 "x_axis"
 OpMemberName %11 1 "y_axis"
 OpMemberName %11 2 "z_axis"
 OpName %11 "spirv_std::glam::core::storage::Columns3<spirv_std::glam::XYZ<f32>>"
 OpMemberName %12 0 "0"
 OpName %12 "spirv_std::glam::Mat3"
 OpName %13 "array_location_calculation::main"
 OpName %2 "one"
 OpName %3 "two"
 OpName %4 "three"
 OpName %5 "four"
 OpName %6 "five"
 OpName %7 "six"
 OpName %8 "seven"
 OpName %9 "eight"
 OpMemberName %11 0 "x_axis"
 OpMemberName %11 1 "y_axis"
 OpMemberName %11 2 "z_axis"
-OpMemberName %12 0 "0"
-OpMemberName %12 0 "0"
 OpMemberName %11 0 "x_axis"
 OpMemberName %11 1 "y_axis"
 OpMemberName %11 2 "z_axis"
+OpMemberName %12 0 "0"
+OpMemberName %12 0 "0"

[khyperia]

Hm, that seems like a bug.

[expenses]

Totally forgot about this - I need to check whether it's still needed.

[eddyb]

Totally forgot about this - I need to check whether it's still needed.

Ah, didn't see this when I set the labels, I'll flip them.