Add arch functions for all non-Matrix arithmetic instructions

[XAMPPRocky]

This PR adds every arithmetic instruction in SPIR-V, except anything related to Matrixes, as I wanted to make a separate PR for that.

There's two functions for every instruction (e.g. i_add/i_add_vector), as I couldn't really find a way to make a function generic over a vector or a scalar, so I just split the implementation into two functions.

Depends on #441 for the const generic in vectors.

[khyperia]

Do we have a need for the scalar functions here? They're already exposed via the traditional operators, feels a little weird to create intrinsics for things we already support in a very built-in way. (I imagined the arch module is for intrinsics that are specific to SPIR-V and cannot be exposed via traditional language constructs, in the same way that core::arch::x86 doesn't expose an intrinsic for "add two integers together")

Also want to loop in @Jasper-Bekkers as a loong while back they were against vector ops, I think we've discussed it more recently and might have changed their mind, but I want to make sure.

Also, how do you imagine the vector ops being integrated into glam? I don't want to merge this without a path forward of how to use these for the operator overloads. (Kind of skipped the design question of what we're going to use these for and how)

[XAMPPRocky]

Do we have a need for the scalar functions here? They're already exposed via the traditional operators

There are some scalar functions here that don't map to an operator. Such as modulo, as % implemented as remainder in Rust. I added the rest for completeness and consistencies' sake, but I don't feel too strongly about their inclusion.

Also, how do you imagine the vector ops being integrated into glam? I don't want to merge this without a path forward of how to use these for the operator overloads. (Kind of skipped the design question of what we're going to use these for and how)

That's a good question, and I think it will require either tightening the coupling with glam so that's not an extern crate (essentially having it as a submodule in the repo that is linked in as a module in the source), this would allow us to implement operator traits for glam types in rust-gpu.

The other option would be decoupling glam from spirv-std, so that glam can depend on spirv-std and then glam can add and maintain the trait impls themselves. This would require removing Sealed requirement for these types, but we can always hide the traits from the docs, and there isn't really an issue if someone else does makes a vector crate that is compatible with rust-gpu, in fact that might be a benefit.

Either option would work I think, tradeoff's are more about who's maintaining the implementation of the link between glam <-> rust-gpu.

[khyperia]

There are some scalar functions here that don't map to an operator. Such as modulo, as % implemented as remainder in Rust. I added the rest for completeness and consistencies' sake, but I don't feel too strongly about their inclusion.

Modulo is exposed as rem_euclid, no?

[XAMPPRocky]

Modulo is exposed as rem_euclid, no?

Huh, I had forgot about that one, good point. Though seeing it now, I do remember some bike shedding over that name. Regardless, I can't see to be able to use that? I tried it on playground and locally and I can't seem to be able to use rem_euclid.

http://shader-playground.timjones.io/ec14ba2de19f76c7460e88d7c04bf09a

[Jasper-Bekkers]

Also want to loop in @Jasper-Bekkers as a loong while back they were against vector ops, I think we've discussed it more recently and might have changed their mind, but I want to make sure.

One of the trade-offs I had missed at the time was the significantly smaller SPIR-V binaries having vector ops would generate. I think this is a good inclusion. 👍

[khyperia]

Huh, I had forgot about that one, good point. Though seeing it now, I do remember some bike shedding over that name. Regardless, I can't see to be able to use that? I tried it on playground and locally and I can't seem to be able to use rem_euclid.

Looks like num-traits doesn't have it, we should probably push it through so rust-gpu "just works". rust-num/num-traits#159

[XAMPPRocky]

I've nudged the PR on num-traits along so that should come eventually. @khyperia So what should I do with this PR? Remove all the non-vector instructions?

[khyperia]

@khyperia So what should I do with this PR? Remove all the non-vector instructions?

I think so! If you have a reasonably clear plan of how to implement vector ops for glam op overloads with this, then yeah!

[XAMPPRocky]

This should be good to go, but needs #476 to land first.