Investigate custom `repr` for GPU memory

[Jasper-Bekkers]

A few options here:

• Hack the compiler to just output the data layout that we want
• Add #[repr(std140)] and #[repr(std430)] to the language frontend (maybe have better names for when we want to support non-Vulkan backends with different layout requirements
• Support #[repr(Rust)] and #[repr(C)] natively through Vulkan's Scalar Block Layout. (Note that this comes with a performance warning).
• All / most of the above

[repi]

* Support `#[repr(Rust)]` 

This is the richest one and most ideal one if/when we have Rust both on the CPU and GPU side.

But also this representation has explicitly no guarantees about ABI compatability or stability between compiler version, so to be safe one would have to have exactly the same rustc compiler for the CPU code and the GPU code to have this match, which is likely unfeasible for a long time.

Need a representation that has a stable ABI, do still hope that Rust in the future will have a subset that can give ABI stability guarantees.

repr(C) is likely the only choice on the Rust CPU side for now and until then.

[Jasper-Bekkers]

From @h3r2tic #[repr(Rust)] would probably also make the SPIR-V code platform specific.

[khyperia]

What exactly does this affect? Things that I can think of:

1. Calling spir-v compiled by other languages from Rust
2. Binding layout?
3. Accessing binary buffer blobs passed into shader (e.g. array of structs)

1 is not on the roadmap. If 2, pointing out explicitly where and what cases it can happen would help. If 3, I wasn't aware that shaders could access binary buffer blobs (I don't think you can in glsl?) - I'd appreciate a pointer in the spec.

[h3r2tic]

If you mean repr(Rust), then it's not very compatible with anything; even two identical structs can be incompatible with each other: https://doc.rust-lang.org/nomicon/repr-rust.html

[khyperia]

Yes, but does that actually affect anything? What ABI boundary are we going through where that will be a problem?

[h3r2tic]

It's probably something for @Jasper-Bekkers :P What was the intended use case? The issue lists possible options, but not motivations.

I was going under the assumption that this would be for buffers (constant, uniform) that want to share types between the CPU and GPU, and access them on the GPU via something similar to Shader Storage Buffer Objects, but with Rust idioms/semantics. On the codegen side, this could end up generating typed loads/stores, or map to simple DWORD fetches like Buffer Textures.

For example, here I have a shader that does a ton of manual unpacking of ray-tracing acceleration data and mesh geometry via bindless buffer textures. Automating that would be great -- but again, I'm not sure if this is the intended motivation behind this issue.