What kinds of optimizations can I rely on with rust-gpu?

[nazar-pc]

I feel like writing code with rust-gpu is a bit more tedious than it should be since I don't know what relatively trivial optimizations it can and can't do today comparing to almighty LLVM, where anything that is easy to deduce I leave where it is the easiest to read and expect compiler to move it in assembly to where it makes the most sense.

A simple example is a code like this in a loop:

const CHUNK_SIZE: u32 = 64;
// ...
    #[spirv(local_invocation_id)] local_invocation_id: UVec3,
// ...

    for _ in .. {
        let x = local_invocation_id.x / CHUNK_SIZE;
        // ...
    }

// ...

Can I expect the compiler to consistently hoist this variable outside the loop or will it translate the thing literally and compute this on every loop iteration?

I'm probably asking too much, but some list of guaranteed optimizations would have been nice to have (if such list exists, I am not aware of it yet).

[LegNeato]

Yeah, this is kind of hard to answer as there are basically three layers:

1. The rust layer
2. The rust-gpu layer
3. The spirv-tools layer (https://github.com/KhronosGroup/SPIRV-Tools/blob/main/source/opt/)

@eddyb is probably the best to say what guarantees if nay happen where.

I will say when we require the rust-gpu layer to output something specific, we put a disassembly test in so that it generates as expected.

[nazar-pc]

Disassembly test is actually great! It is exactly the kind of guarantee I would expect (even though I can't read SPIR-V yet, LLMs can). A human-readable digest would still be nice to have though.

[Firestar99]

Can I expect the compiler to consistently hoist this variable outside the loop or will it translate the thing literally and compute this on every loop iteration?

I'd answer it differently: It doesn't really matter how shitty our SPIRV output is. Once you give that SPIRV to the driver, it'll spin up an entire LLVM toolchain to compile it down to machine code for the GPU you're running. (At least AMD and Nvidia use an LLVM backend, can't comment on other drivers). You should look at their output instead of our SPIRV to know if something is getting properly optimized. And in my experience, the answer was always yes.

AMD provides their windows shader compiler within their Radeon GPU Analyser (RGA) package and it's available within RenderDoc as a viewing option for shader code. (Godbolt only exposes it with HLSL and Shader Playground can do SPIRV to AMD ISA become incredibly slow). AMD also provides public specs on their ISA.

One thing you'll quickly notice on AMD's ISA is that they differenciate between scalar s_ and vector v_ instructions, and are capable of analyzing shaders for which variables are the same across all threads (scalar) and which ones may differ between threads (vector). If you're running that kind of analysis, you better be capable of hoisting out a variable out of a loop.

[nazar-pc]

While there is truth to what you're saying, I don't think it is completely accurate that it doesn't matter at all. There is a lot more information in Rust type system about what the developer intended to do than in the produced SPIR-V. So while some things will be optimized, others wouldn't. And I think there is still value in providing cleaner/more optimized SPIR-V in general.

Also I'm hoping that translation from Rust to SPIR-V will be easier to follow than using GPU-specific tooling and trying to understand what Rust code corresponds to what GPU-specific assembly after it went through several compilers already.