Internal SIMD layout specification is not flexible enough for SPIR-V

[fu5ha]

In rust-gpu we implement a codegen backend for SPIR-V.

SPIR-V supports vector types, which we currently model by analogue of Rust Abi::Vector types, i.e. #[repr(simd)]. However, SPIR-V supports vector types of the same size that have a different representation depending on their element, which is incompatible with how Rust currently handles vector type data layouts.

Base SPIR-V Vector Layout

The default representation of SPIR-V vectors is specified in section 2.2.2 and 2.18.1 of the SPIR-V spec. This default representation is effectively an align of the underlying element type and size of element_size * count. As specified in section 2.16, the count is limited to 2, 3, or 4 elements, unless certain capabilities are enabled which allow 8 and 16 element vectors as well.

Extra requirements

However, the actual layout requirements of vector types change and can get rather messy depending on where and how they are used. As far as the SPIR-V spec itself is concerned, the above are the only rules. In practice, you must run SPIR-V code through a client implementation of some graphics API. For Vulkan, this adds extra rules for how you can load vector types from different kinds of buffers. The rules are specified in the Vulkan specification here.

Basically, under so-called scalar alignment rules (the least restrictive), stuff in buffers behaves just like repr(C) layout, with vectors retaining the property of having the same alignment as their base element.

Under the more restrictive layout rules (i.e. older versions of the spec without extensions enabled), vectors start to behave more like on x86 or aarch64: two component vectors have an alignment of twice their base element, and 3 and 4 component vectors both have alignment of 4 times the element.

Something that is unclear to me is whether it's even sensical within Rust's type model to allow the same type to exhibit different alignment requirements in different locations. If not, it makes most sense to me to always follow the less restrictive model and force the programmer to respect the more restrictive rules manually where applicable.

Alternative solutions

We already have a set of #[spirv(X)] attributes. It would be possible, though more annoying and perhaps less flexible, for us to implement a #[spirv(vector)] attribute which handles things separately. Right now we are experimenting with basically doing this to patch internal simd vector layouting.

[VorpalBlade]

If not, it makes most sense to me to always follow the less restrictive model and force the programmer to respect the more restrictive rules manually where applicable.

I don't know much about SPIRV, but what would the effects be of getting those rules wrong? Would it be unsound (cause UB) or just fail to compile or fail to run?

[workingjubilee]

I don't know much about SPIRV, but what would the effects be of getting those rules wrong? Would it be unsound (cause UB) or just fail to compile or fail to run?

In theory one of the latter should result. SPIRV does provide enough validation rules to declare this kind of problem incorrect at compile time.

In practice, we're talking about dynamic JITs that are assuming a valid output from a higher-level language's compilation, so... we should assume it would be UB.

[fu5ha]

In rust-gpu we run spirv-val and spirv-opt on emitted spir-v unless you specifically disable them, which detect the specific issues that arise for buffer block layout rules quite well

[workingjubilee]

Oh good.