Add Const Generic Image Type

[XAMPPRocky]

This PR refactors Image in the backend to not use attributes to determine things like dimensionality and depth, and to instead accept them as const generics as parameters. This has the advantage of only needing a single Image type as opposed previously to requiring a new type for each combination, and also allows us to have enums to represent all of the possibilities rather than using u32s directly.

Additions

• macros::Image a new procedural macro for defining Image types.
• image::SampleType a trait that allows us to be generic of the underlying sampled type of the image.
• image::ImageCoordinate a trait built on top of Vector for parameterising image coordinate vectors based on the sampled type, dimensionality, and arrayed-ness of the Image.
• A new spirv_types crate for holding types that are useful in both spirv-std and spirv-std-macros.

Re-works

• crate/spirv-std-macros has been moved into the spirv-std folder as macros beside the shared crate, this keeps the folder structure cleaner.

[XAMPPRocky]

Alright, I've implemented all of the feedback.

I think I might prefer nuking the old image system at the same time, having duplication for even a short amount of time is a big maintenance burden and causes confusion.

Well if we nuke the old system, we can't upgrade rust-gpu in Ark until C-like enums are stabilised or we change the parts of Ark to not use reflection for entry points. So I do think it's worth keeping them both for a short time, I've also added a deprecated message if you have the const generics feature enabled, so if you can use it, it warns to move to the new type.

[khyperia]

LGTM pending nits.

Just realized, do we want to export common type aliases? Say, for all the types we already have explicitly defined, e.g. pub type Image2D = Image!(2d, type=f32, sampled) - might be nice for both examples for users of how to use the macro, plus saves users having to figure out e.g. what the heck sampled means and if they want it or not.

[khyperia]

Oh yeah, also adding docs to the rust-gpu book on the macro syntax would be good, but that can be done in a follow-up if you'd like (file an issue if so).

[XAMPPRocky]

Oh yeah, also adding docs to the rust-gpu book on the macro syntax would be good, but that can be done in a follow-up if you'd like (file an issue if so).

The syntax is documented on the macro itself so when you visit the Image! API docs you'll see it there.

[khyperia]

The syntax is documented on the macro itself so when you visit the Image! API docs you'll see it there.

People look at the book instead of the API docs when trying to figure out language constructs (where language = DSL in this case), e.g. u32 is documented both here https://doc.rust-lang.org/stable/std/primitive.u32.html and here https://doc.rust-lang.org/book/ch03-02-data-types.html . I think it'd make rust-gpu more accessible and easier to use if documentation was available in both places - something as core to graphics programming as images should be documented in the rust-gpu book, especially if it's not "normal" rust type syntax.

Resolved