# glam: 3D math for Rust with SIMD-aligned types and compile-time feature gating

> glam is a Rust crate for 3D math used in game and graphics code, providing f32 and f64 vectors, matrices, quaternions and affine transforms with SIMD storage on x86, x86_64, aarch64 and wasm. Version 0.34.1 is on crates.io under MIT OR Apache-2.0, and 0.34.0 is declared the final breaking pre-1.0 release.

**bitshifter/glam-rs** — A simple and fast linear algebra library for games and graphics

- Repository: https://github.com/bitshifter/glam-rs
- Stars: 2,074 · Forks: 207
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-09 · Updated: 2026-10-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/bitshifter-glam-rs

## glam is scoped to game and graphics math, not general linear algebra

glam covers the 3D math operations that run repeatedly in a game loop: position vectors, rotation quaternions, transformation matrices and affine transforms. Its Cargo.toml description is a simple and fast 3D math library for games and graphics, and that scope is genuinely narrow. Cargo.toml categories are game-engines and no-std, which names its intended home more precisely than any marketing copy.

No sparse matrix types exist in the library. No eigenvalue or singular value decomposition, no facilities for statistics or signal processing. Anyone coming from scientific computing who expects a general linear algebra library will find the type list stops exactly at the operations a renderer or physics simulation needs.

Projects that use multiple libraries with different math type APIs can bridge them through the mint-05 optional dependency. mint 0.5 is a shared interoperability layer for 3D math, and when a game engine dependency and a physics library each implement mint traits, glam types can be converted through that layer rather than requiring manual component copies.

## f32 and bool types build by default; f64 and integer types require explicit features

All types are included with the default feature set because all-types is enabled by default. Within that, f32 and bool types are compiled into the core crate, while f64, integer and size-based types are generated code gated behind optional features.

Feature breakdown: float-types enables f64 types (DVec2 through DVec4, DMat2 through DMat4, DQuat, DAffine2 and DAffine3); integer-types enables i8, u8, i16, u16, i32, u32, i64 and u64 vector types; size-types enables isize and usize vectors; all-types enables all three. Disabling the default features and enabling only what a project needs trims the compile surface, which the README identifies as a way to reduce compile times.

Boolean types also come in two forms. BVec3 and BVec4 are scalar; BVec3A and BVec4A are SIMD-aligned variants matching the layout of Vec3A and Vec4 respectively. A comparison against a Vec3A returns a BVec3A rather than a BVec3, because both types must live in the same 16-byte aligned slot.

## glam is on crates.io under the name glam, and Rust 1.85.0 is required

glam is published on crates.io under the name glam. Adding it follows the standard Cargo dependency pattern; version 0.34.1 is the current release in the crate metadata. Rust 1.85.0 is the minimum version required, set via the rust-version field in Cargo.toml. A toolchain older than 1.85.0 will refuse the build.

Documentation lives at https://docs.rs/glam, per the documentation field in Cargo.toml. No full API listing appears in the README itself, so docs.rs is where method signatures, examples and module documentation are maintained.

For an initial integration, the camera module provides constructors for view and projection matrices. Rendering work typically starts there: constructing a perspective or orthographic projection matrix rather than assembling the values by hand. No additional feature flags are needed for f32 types; they are in the default build.

## Vec3A, Mat3A and Affine3A carry padding that SIMD alignment requires

Eight types in glam use 128-bit SIMD vector storage on supported architectures: Vec3A, Vec4, Quat, Mat2, Mat3A, Mat4, Affine2 and Affine3A. That 128-bit storage puts all of them at 16 bytes aligned. Because alignment requirements widen the slot, some types are larger than their component values require.

Vec3A holds three f32 components. Three f32 values occupy 12 bytes, but the type sits in a 16-byte slot, leaving four bytes of padding inside the struct. Mat3A holds three Vec3A values and carries the per-row overhead three times. Vec3A, Mat3A, Affine2 and Affine3A are the four cases named in the README as types with wasted space.

Serialized data needs to account for this. A Vec3A byte representation is 16 bytes, not 12, and those extra four bytes are padding rather than data. Projects that write to compact binary formats or pass types over a network need to handle the discrepancy, or choose Vec3 instead of Vec3A where that padding is unacceptable. Non-A variants use scalar storage and carry no padding.

## SSE2 and NEON are automatic on their home targets; x86 and wasm32 need RUSTFLAGS

SIMD availability depends on the compile target, and defaults are not symmetric. On x86_64, SSE2 is enabled automatically; no configuration is needed. On aarch64, NEON is enabled automatically. On x86, SSE2 must be activated by adding `-C target-feature=+sse2` to RUSTFLAGS. On wasm32 or wasm64 targets, add `-C target-feature=+simd128` to RUSTFLAGS.

On wasm targets, tests pass but no benchmark data has been published for the simd128 path. Whether a specific workload gains from SIMD on wasm is something each project has to measure; the README does not make a performance claim for that target.

core-simd enables SIMD through Rust's portable simd module, but that module is still unstable in the language and requires a nightly toolchain. It is not a production option today.

scalar-math is the explicit off switch for all SIMD paths. Enabling it forces scalar storage and native alignment for every type, including those that normally use SIMD. This feature exists primarily for the project's own validation of its scalar fallback paths, but any downstream crate can enable it.

## no_std requires libm; the nostd-libm feature relaxes the constraint for library authors

Using glam in a no_std environment takes two steps: disable the default features (which removes the std dependency) and add the libm feature to supply math functions that would otherwise come from std. That Cargo.toml declaration is:

```toml
[dependencies]
glam = { default-features = false, features = ["libm"] }
```

A project that needs to compile for both std and no_std environments can use separate wrapper features in its own Cargo.toml. A pattern in the README uses a std wrapper feature and a libm wrapper feature, letting the project compile under default features (std) or with them disabled (no_std with libm).

nostd-libm is a third option: it includes a libm dependency unconditionally but allows callers to override with std if they prefer. Library crates targeting embedded hardware without std can use this to let consumers re-enable std without needing an explicit feature flag choice.

## mint-05, rkyv-08 and serde each use versioned feature names to survive dependency bumps

Optional dependencies follow a naming convention worth understanding before adding any of them. Pre-1.0 dependencies that appear in glam's public API carry versioned feature names: approx-05 for approx 0.5, rand-010 for rand 0.10, rkyv-08 for rkyv 0.8, encase-012 and encase-013 for two versions of encase, mint-05 for mint 0.5, speedy-08 for speedy 0.8. Per the README, this scheme lets a new version of a dependency be added without a breaking change to glam itself. When rkyv releases a new version, glam can add a new versioned feature alongside rkyv-08 without forcing an upgrade on existing users.

For serialization, the serde feature adds Serialize and Deserialize for all glam types. Serialization should work between builds with SIMD and builds without, covering the case where the producer and consumer of data run on different hardware.

bytemuck allows casting glam types to byte slices. zerocopy-08 adds zerocopy trait implementations. For GPU work, the cuda feature aligns types to match CUDA's built-in vector type requirements, documented in Nvidia's programming guide.

## Version 0.34.0 closed the pre-1.0 breaking window under MIT OR Apache-2.0

Version 0.34.0 ended the pre-1.0 breaking change period, with version 1.0 as the stated next target. Current release on crates.io is 0.34.1. Progress toward 1.0 is tracked in a GitHub Discussions thread linked from the README, and the repository was last pushed on 2026-10-06.

Under Rust's semantic versioning convention, a 0.x crate can make breaking changes at each minor bump. Closing that window means 0.34.x is stable in the sense that no further breaking changes will arrive before 1.0. Projects that have held off on glam due to pre-1.0 instability have a concrete signal to watch for.

License in Cargo.toml is MIT OR Apache-2.0. Two license files sit at the repository root: LICENSE-APACHE and LICENSE-MIT. That dual licensing is common in the Rust ecosystem and lets a downstream project satisfy its own requirements by choosing either.

An AI_POLICY.md also sits at the top level of the repository. Neither the README nor Cargo.toml covers its contents, so its stance on AI-generated contributions is not documented here.

## Conclusion

glam suits any Rust game or graphics project that needs vectors, matrices, quaternions and affine transforms in f32 or f64, with SIMD on x86, x86_64, aarch64 and wasm. SSE2 is on by default for x86_64 and NEON for aarch64; x86 and wasm32 need a RUSTFLAGS entry. Skip it when you need a sparse matrix solver or a type with no internal padding at all. Before adopting, confirm the 16-byte alignment of Vec3A and Mat3A is acceptable for your use, since those types carry wasted space by design. Version 0.34.0 closed the pre-1.0 breaking change window; check the Discussions thread linked in the README to confirm whether 1.0 has landed before pinning a version.

## FAQ

### What is glam in Rust?

glam is a Rust crate for 3D math targeting game and graphics code. It provides vectors, matrices, quaternions and affine transforms in f32 and f64, and is published on crates.io under the name glam.

### How do I add glam to a Cargo.toml project?

glam is published on crates.io under the name glam, so it follows the standard Cargo dependency format. Version 0.34.1 is the current release, and Rust 1.85.0 is the minimum toolchain version required.

### What is the difference between Vec3 and Vec3A in glam?

Vec3A uses 128-bit SIMD storage and is 16 bytes aligned, which introduces padding beyond the three f32 components. Vec3 uses scalar storage with no padding. Vec3A is one of the four types the README identifies as having wasted space due to SIMD alignment requirements.

### Does glam support no_std environments?

Yes. Disable the default features and add the libm feature to build without the standard library. The nostd-libm feature is also available for library authors who want std as an optional override without requiring callers to choose explicitly.

### What does the scalar-math feature do in glam?

Enabling scalar-math disables SIMD support and switches all types to native alignment. It exists primarily for the project's own validation of its scalar fallback paths, but downstream crates that need types without internal padding can use it.

## Sources

- [bitshifter/glam-rs on GitHub](https://github.com/bitshifter/glam-rs)
- [Issues](https://github.com/bitshifter/glam-rs/issues)
- [License: Apache-2.0](https://github.com/bitshifter/glam-rs/blob/main/LICENSE)
- [README](https://github.com/bitshifter/glam-rs/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bitshifter-glam-rs