-
Notifications
You must be signed in to change notification settings - Fork 162
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
Comments
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. |
It's hard to think of any change that would justify the massive efforts required in other crates for a breaking change. |
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. |
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. |
Thanks. That's probably a good decision at this point. Churn in low-level crates forces churn in other crates. |
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.
The text was updated successfully, but these errors were encountered: