spirv: vector attribute

[Firestar99]

stacked spirv PR 2/3:

• spirv: derive Hash and impl AsRef #675
• this PR
• Revert: Don't use bytemuck derive on spirv. #677
• rust-gpu integration: abi: Make glam types abi layout match CPU Rust-GPU/rust-gpu#380

Objective

• replace #[repr(SIMD)] with #[rust_gpu::vector::v1]
• allows rust-gpu to remove hacks around allowing old glam-style #[repr(SIMD)]
• #[rust_gpu::vector::v1] is a custom rust-gpu attribute that marks structs to be compiled into spirv OpTypeVector instead of OpTypeStruct, vector primitives are needed for many intrinsics

[bitshifter]

What are the alignment implications of rust_gpu::vector::v1? One of the reasons I avoided repr(align) on spirv is that repr(simd) vectors had their own alignment and I felt that repr(align) could be misleading if it didn't happen to match the alignment on repr(simd). Ultimately this is only really going to be an issue for people working on spriv, so I don't really mind how it works but if rust_gpu::vector::v1 alignment is different to what is specified by repr(align) here it might confuse people.

[Firestar99]

What are the alignment implications of rust_gpu::vector::v1?

None, and that's amazing! We can just leave the layout calculations to rustc and just copy whatever size, alignment and offsets it gives us to spirv. The attribute merely tells our backend to emit the struct as an OpTypeVector instead of an OpTypeStruct, which only requires that the members are 2..4 primitive types.

In fact, spirv types like OpTypeStruct or OpTypeVector don't necessarily need any layout, it only needs an "explicit layout" if it is read from or written to an external buffer, that may be viewed by other shaders or the CPU. And "explicit layout" only requires the struct to be "sane", like all members have offsets and no overlapping offsets, otherwise it does not care. So we can have our Vec3 and Vec3A be distinct OpTypeVectors with varying layouts.