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.