Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Needs to reach version 1 #463

Open
John-Nagle opened this issue Jan 12, 2024 · 5 comments
Open

Needs to reach version 1 #463

John-Nagle opened this issue Jan 12, 2024 · 5 comments

Comments

@John-Nagle
Copy link

Many graphics crates use glam. Not all use the same version. This results in having to pin old versions of crates to get them all on the same version of glam.

The graphics ecosystem needs a solid version 1. From there, enhancements can be added, but don't break the existing API. Thanks.

@bitshifter
Copy link
Owner

There is one largish change I have in mind for glam before calling it 1.0 but I need to find the time to experiment with it, write it up and discuss with the community. One that happens (or the idea is rejected by the community) then I think I could call it 1.0.

@John-Nagle
Copy link
Author

It's hard to think of any change that would justify the massive efforts required in other crates for a breaking change.

@bitshifter
Copy link
Owner

In short I'm looking at moving away to defaulting some types to using SIMD registers and requiring 16 byte alignment and instead making separate explicit types for that. There are a bunch of reasons why. I'll talk about it more once I've had time to collect my thoughts and written about it, I doubt it will break much existing code.

@bitshifter
Copy link
Owner

I spent some time working on this idea of splitting types into explicit float and SIMD versions, much like Vec3 and Vec3A but for all of the other types that use SIMD, e.g. splitting Vec4 into Vec4 and Vec4A and so on. For anyone who is interested the changes are here main...experimental. I was attempting to modify a fork of bevy to use this branch which made it pretty clear that this would be quite a disruptive change, so I have backed away from this idea. It also introduces way more types to glam.

The reason I was considering it in the first place is there is a cost to many types being 16 byte aligned and it is not always clear that the benefits outweigh this cost. In microbenchmarks they do but microbenchmarks are not representative of real game code.

In any case, people seem largely happy with glam as it is and as you say many projects depend on it, so I think it's best to not make any large changes at this point. Now that I've finished with the aarch64 neon work I'll focus on getting to 1.0, which will mostly involve making sure any outstanding issues that would be breaking changes are done before then.

@John-Nagle
Copy link
Author

Thanks. That's probably a good decision at this point. Churn in low-level crates forces churn in other crates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants