Vector types

[khyperia]

spir-v has vector types that are dramatically useful on e.g. nvidia hardware for optimizing loads/stores. At first, let's just directly expose vector types, instead of trying to do things like auto-vectorization.

1. Rustc already has the notion of vector types, and we directly translate them to spir-v vector types. We need to investigate under what conditions rustc emits vector types, and if we can re-use the same framework.

   rust-gpu/rustc_codegen_spirv/src/abi.rs

   Lines 332 to 339 in 9697c22

   	Abi::Vector { ref element, count } => {
   	let elem_spirv = trans_scalar(cx, ty, element, None, is_immediate);
   	SpirvType::Vector {
   	element: elem_spirv,
   	count: count as u32,
   	}
   	.def(cx)
   	}

2. If we cannot re-use the same framework, create an attribute to specify a type is a builtin vector, recognize the attribute in abi.rs (example for storage classes), and emit a vector type. Perhaps do a mix of the two, e.g. if rust supports f32x2 and f32x4, but not f32x3, then we need to define our own f32x3.
3. Investigate the spec: is emitting a spir-v "OpTypeVector" enough, or are there additional decorations/etc. we need to apply to get it to be a proper "vector type"?

   rust-gpu/rustc_codegen_spirv/src/spirv_type.rs

   Line 166 in 9697c22

   SpirvType::Vector { element, count } => cx.emit_global().type_vector(element, count),

4. Implement the above in spirv-std, adding things like swizzling ops and other shenanigans (can come later).

This seems like a good not-quite-first-but-kinda-first task for someone other than me to do. Step 2 is a little involved and will likely need some mentorship - abi.rs is hecking wild - but getting more people who know how abi.rs works would be really really good.

[khyperia]

Possibly relevant: https://github.com/hsivonen/simd/blob/045d4dae4e65f99fd43cd9042f5132812cae717e/src/lib.rs#L75-L79

#![feature(repr_simd)]
#[allow(non_camel_case_types)]
#[derive(Debug, Clone, Copy)]
#[repr(simd)]
pub struct f32x4(f32, f32, f32, f32);

[khyperia]

It looks like item 2 is not necessary - seems like #[repr(simd)] is all that needed. So yeah, definitely good first issue! Mostly just step 4 is necessary, although a more senior person digging deeper into points 1 and 3 would be nice - I don't think there's any surprises there, though (but it's good to be sure).

f32x4 is already implemented in spirv-std by copying the above type, but it's just that, and needs all the impls and operators and whatnot (as well as all the other types). Defining all that repitition using macros seems neat.

[nipunG314]

Hi, I would be interested with working on this.

From what I understand in this thread, the first thing to do would be to write the operators and impls for f32x4 using macros?

[khyperia]

Awesome!

This issue is a bit out of date, though: #71 added quite a few vector items. However, it wasn't very cleanly or thoroughly implemented, and needs significant work. Some tasks remaining are:

1. vec4 and f32x4 are duplicated right now. One of them needs to be removed. Discussing which naming scheme to go with in discord would be nice, if you're able to join there!
2. A lot of cruft from glam was copied over, this needs to be fixed (e.g. reciprocal), and many weird comments.
3. There's a lot of duplication: it'd be nice if we could deduplicate with macros or somesuch.
4. The clippy use_self lint is disabled on spirv-std, primarily due to violations in the vector code, it'd be good to fix those.
5. Tests are disabled on spirv-std right now, either remove the tests or enable them.

[nipunG314]

Sure. I'll ping you on #rust-gpu on Discord.

[khyperia]

With glam and whatnot in, this is pretty much resolved.