Replace vek with glam.

[LegNeato]

This fixes #179.

[jorge-ortega]

Seems like we're resolving to multiple versions of glam between what's re-exported through cust and what's pulled it in directly in some places. We might want to consider using workspace dependencies to ensure we use the same version across our crates.

[LegNeato]

Yeah, I just did some dumb find and replaces 😄 . I intend to actually look at this in a bit.

[adamcavendish]

I personally think that we don't need vek nor glam for dim1,dim2,dim3 conversion. Mostly users won't use a vek nor a glam vectorized type for creating kernel invocations. To use glam or vek, people should add that as a dependency to their kernel projects instead.

[LegNeato]

I don't quite know the history, but rust-gpu didn't have it and it was specifically added. There likely was a reason vek was added here as well.

[jorge-ortega]

After taking a closer look, I do find the thread/index functions (index_{2,3}d, {block,thread}_idx, etc.) returning a specific vector type of choice a bit of an overstep. vek and glam both implement From for tuples and arrays. It would better to see these functions return either one of those so users can call into to convert to the vector type of their choice. This would also avoid imposing a vector type dependency in cuda_std.

[jorge-ortega]

spirv-std seems to use glam as their vector of choice for fragment shader data. Cuda kernel parameters are way more general though. The type used to return thread indices may have very little to do with actual data types being processed, other than to know which elements to index. Seems hard to justify the choice of a vector type just to get the set of thread indices (edit: aside from the convivence of labeling x, y, z components).

For the record, I do think we should standardize on glam where applicable. It's more broadly used across the ecosystem, and I prefer being able grok a codebase that isn't all macros.

[LegNeato]

I think ideally we'd have a type or trait in core that SIMD and GPUs (and wasm SIMD) can all use.

I've also been waiting for externally implementable items to land, as maybe we just define our own trait and let end-user code plug into it, similar to allocators and panic handlers.

[jorge-ortega]

I have a branch of this on my fork that's rebased on main and update to fix the remaining errors.

[LegNeato]

Cool, I can close this one out. Sorry, have had some personal stuff I've had to deal with lately so I've been a bit busy. Hoping it gets cleared up at the start of May!

[LegNeato]

Oh whoops @jorge-ortega , misread and thought you landed it ha. Is it ready to land, do you want to finish it if not, or shall I cherry-pick here and finish it?