Unable to use "bytemuck" feature on spirv target

[tmvkrpxl0]

Describe the bug

It's now impossible to enable "bytemuck" feature on spirv target.

To Reproduce

Enable bytemuck feature on spirv target

Expected behavior

I expected it to compile successfully

System information (please complete the following information):

• OS: KDE Neon 24.04 (based on ubuntu lts 24.04)
• Architecture x86_64

Additional context

I opened relevant issue on bytemuck's repo: Lokathor/bytemuck#315
Turns out simd representation cannot be used with bytemuck's derive.
The actual issue isn't the spirv target itself, instead it's just simd representation and bytemuck's derive being incompatible. but as simd representation is only used when spirv target is enabled, it only fails on spirv target.

[bitshifter]

I wonder if this is a regression, I switched to using derive for glam's bytemuck implementation not long ago because it adds some compile time safety checks.

Is bytemuck used on spirv targets or is this more an observation?

[tmvkrpxl0]

Folks at rust-gpu uses it to pass data to gpu shader

[bitshifter]

That sounds like they pass data from CPU to GPU, so not from spirv?

[tmvkrpxl0]

the shader code is also written in rust in this case which is compiled for spirv target. In my project I share type definition with main program and gpu shader so both spirv and x86 target uses it.

[Firestar99]

As a rust-gpu maintainer, we are aware that rustc wants to deprecate #[repr(SIMD)] anyway, so at some point we need to migrate away from it anyway. Personally, I haven't run into this issue yet, could just be me using an older glam version though.

[bitshifter]

glam switched to using derive in the most recent 0.30.4 release, which turns out was a breaking change for spriv :(
perhaps I could look at adding spriv to my CI to catch things like this, I don't know how difficult that would be.

The benefit for using derive was to catch misuse, but I could probably restore the old code just for spirv, until repr(simd) goes away at least.

[eddyb]

As a rust-gpu maintainer, we are aware that rustc wants to deprecate #[repr(SIMD)] anyway, so at some point we need to migrate away from it anyway.

Note that the form Rust-GPU uses is already gone upstream, and I had to pull some nasty tricks with query overrides to remove type-checking steps, and reimplement type layout logic, just to bring it back for a bit longer.

So it's living on borrowed time (specifically #[repr(simd)] struct Vec2 { x: f32, y: f32 } style definitions), even in Rust-GPU.

but I could probably restore the old code just for spirv, until repr(simd) goes away at least

That makes most sense to me - I could not come up with a #[repr(simd)] replacement that doesn't require some form of pointer casting (e.g. like glam Deref-ing between definitions with equivalent memory footprint), and I still hope we can release a Rust-GPU version before unleashing all the pointer/typed-memory legalization work onto it.

[bitshifter]

OK, I've kept derive for non-spirv and restored the old impls for spirv only.

However it occurs to me that size and alignment of types on spirv is probably different to normal in some cases and may violate the rules of some bytemuck traits. I don't think I know enough about spirv to say.

I'll try get this out in a release this week or the weekend but if anyone checks it on the git version lkm if there's any issues.

[Firestar99]

Tested main successfully on a small test game and rust-gpu's compiletest 🎉

One unrelated note on using glam's git: Adding this to your Cargo.toml is not sufficient on my machine:

[patch.crates-io]
glam = { git = "https://github.com/bitshifter/glam-rs.git", branch = "main" }

It fails with this, even tough I obviously have an ssh key setup and authed in github:

    Updating git repository `https://github.com/bitshifter/glam-rs.git`
    Updating git submodule `git@github.com:bitshifter/glam-codegen.git`
error: failed to load source for dependency `glam`

Caused by:
  Unable to update https://github.com/bitshifter/glam-rs.git?branch=main#b3f3b08d

Caused by:
  failed to update submodule `codegen`

Caused by:
  failed to fetch submodule `codegen` from git@github.com:bitshifter/glam-codegen.git

Caused by:
  failed to authenticate when downloading repository

  * attempted ssh-agent authentication, but no usernames succeeded: `git`

  if the git CLI succeeds then `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  no authentication methods succeeded

I think what trips it up is your .gitmodules having an ssh link, and cargo internal cloning doesn't seem to like non-http links.

glam-rs/.gitmodules

Lines 1 to 3 in b3f3b08

	[submodule "codegen"]
	path = codegen
	url = git@github.com:bitshifter/glam-codegen.git

Workaround: add this to your config.toml, so cargo uses your cmdline git instead of it's internal one:

[net]
git-fetch-with-cli = true

[bitshifter]

Hmm, maybe I should use a http link instead