First class swizzles

[voidentente]

What makes shading languages stand out is that they are adapted to their use. Rust wasn't designed to be a shading language, and this lack of adaptation becomes obvious as friction.

One such example is swizzles. Glam has to resort to very unergonomic methods:

d = d.with_xy(d.yx());

It's not a joy to write this over and over and over. In GLSL, this is so much simpler:

d.xy = d.yx;

But Rust-GPU is in a position where it could add support for first class swizzles.

• The goal is user ergonomics -> language server support.
• Adapting rust-analyzer to Rust-GPU is not suitable, so Rust-GPU must adapt to rust-analyzer -> the language specification.
• This means swizzles would have to be disguised as normal struct fields.
• On targets other than spirv the user could config out these fields.
• On spirv, where the Rust-GPU backend would support first-class swizzles, it would mark the swizzle fields, substituting reads from and writes to these fields with the according reads from and writes to the aliased fields.

Concrete changes: The codegen backend must be aware of a new attribute, spirv(swizzles), which structs can be marked with.

Concrete example:

#[cfg_attr(target_arch = "spirv", spirv(swizzles))]
pub struct Vec2 {
    pub x: f32,
    pub y: f32,

    #[cfg(target_arch = "spirv")]
    pub xx: Vec2,
    #[cfg(target_arch = "spirv")]
    pub xy: Vec2,
    #[cfg(target_arch = "spirv")]
    pub yx: Vec2,
    #[cfg(target_arch = "spirv")]
    pub yy: Vec2,
    #[cfg(target_arch = "spirv")]
    pub xxx: Vec3,
    #[cfg(target_arch = "spirv")]
    pub xxy: Vec3,
    
    // etc..
}

Glam's vectors wouldn't profit from this, of course - at least not immediately - since they would need to reflect the support. But it would at minimum let users define their own vectors, and establish the groundwork for first class swizzle support elsewhere.

And regarding borrowing, the simplest solution would be for Rust-GPU to simply interpret it as "copy then borrow".

// This doesn't borrow v.zyx but copies v.zyx and then borrows it:
let zyx_mut = &mut v.zyx;
let xyz_mut = &mut v.xyz;
f(zyx_mut);
f(xyz_mut);
// No rules broken.

Alternatively, if this behavior is too unexpected, Rust-GPU could also lint it or simply forbid it entirely.

Let me know what you think, and how feasible this would be.

[voidentente]

AFAICT from an implementation angle, altering projections of swizzles should be doable as a MIR hook, but I don't yet know how the struct layout would be intercepted. But then again, I'm not knowledgeable about rustc codegen machinery.

fn provide(&self, providers: &mut rustc_middle::util::Providers) {
    // ..

    providers.optimized_mir = swizzle::MIR_HOOK;
}

pub const MIR_HOOK: for<'tcx> fn(TyCtxt<'tcx>, LocalDefId) -> &'tcx Body<'tcx> =
    |tcx, local_def_id| {
        let mut body = (DEFAULT_QUERY_PROVIDERS.optimized_mir)(tcx, local_def_id).clone();
        reproject_swizzles(tcx, local_def_id.to_def_id(), &mut body);
        tcx.arena.alloc(body)
    };

[voidentente]

Alternatively, if we can't physically remove the swizzles from the adt def, we could make them ZSTs. That way, they don't affect layout and we can just compile them normally. However, the ZST swizzle type would need to mimic all the APIs of the vector type parameter to be useful. These APIs would be stubs that then get redirected in MIR pass.

#[cfg_attr(target_arch = "spirv", spirv(swizzles))]
pub struct Vec2 {
    pub x: f32,
    pub y: f32,

    #[cfg(target_arch = "spirv")]
    pub xx: PhantomData<Vec2>,
    #[cfg(target_arch = "spirv")]
    pub xy: PhantomData<Vec2>,

    // etc..
}

[Firestar99]

The biggest advantage of rust-gpu IMO is that using the same language for CPU and shaders allows you to easily share struct definitions and algorithms between both platforms. If we implement a rust-gpu only language feature, you won't be able to share that code anymore, destroying one of our main advantages. So if you want real swizzling, you need to go upstream.

To put a number on it, I'd estimate that 90%+ of code written for rust-gpu is also compiled for cpu platforms. Some reference points:

• trivial no-share: Some projects can get away with not sharing anything, but they usually are trivial or the shaders are ported. -> 0% but rare
• shader crate only: rust-gpu-template showcases the cpu crate directly depending on the shader crate to import all the struct definitions. Most of my projects are structured like this. -> 100%
• dedicated shared crate: rust-gpu/examples has a shared crate (shared between platforms) and dedicated shader crates, so you could make use of swizzling within the shader crates. If it weren't for the cpu runner evaluating the sky shader or the sky shader having a unit test that is run on the CPU. -> 90%
• single crate: graphite's raster-nodes crate has a shader-nodes feature, which includes the raster-nodes-shaders crate, and their build script compiles shader-nodes with --no-default-features to break the recursion. So everything is shared within a single shader + cpu only crate. -> 100%

[voidentente]

Rust-GPU's flexibility is an advantage, don't get me wrong. But not everyone needs to run code that should obviously run on the GPU on the CPU. Many shaders are explicitly designed for GPUs. Running them on CPU doesn't make sense because there would be more optimal solutions utilizing SIMD or AVX which aren't available on GPU. Besides, the project is called Rust-GPU, so the GPU should be the primary target. So I'd argue it still makes sense as an opt-in, which this is, for users that only target GPU. Code that wants to be cross-compatible will just have to not use swizzles. But it'd at least make GPU-only less miserable.

Mind you struct definitions still can be shared between both platforms. The CPU doesn't see the swizzle fields because they're configured out, and the layout is the same, so no problem there.

[voidentente]

And regarding going upstream, I find it very unlikely for rustc to integrate swizzling. So this is the only real chance.