Add Neon support to glm #945
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A few simple functions that use Neon as compiler does not use the full potential of Neon For now, -DGLM_FORCE_NEON is required until it's the default
|
Anyone to review this? |
|
Is it also in your view of glm to use clang or gcc's extensions to make things easier? I'm talking about the vector extensions so ARM or x86 could be implemented inside shared code. It won't work with MSVC though, so it could be an issue, unless you know of a vector extension for the MS compilers (or even icc)? |
Groovounet
added a commit
that referenced
this pull request
Sep 7, 2019
|
This PR is merged in master branch for GLM 0.9.9.6 release. Thanks for contributing, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi there,
I'd like to add some Neon to the simd support in GLM.
We at Magic Leap use glm quite a bit on Aarch64 (aka Arm64) cores, but we noticed that the compiler (prebuilt Android O llvm-clang base) does not generate enough of Neon to take advantage of the full potential of our architecture.
For now, this PR enables the SIMD path only if GLM_FORCE_NEON is defined. But the goal is maybe to enable it by default.
We don't expect a big performance gain (or loss) from this PR, but if it can be merged, a few other PRs can take care of the matrix operations (like multiply or inverse). For the inverse case, we can get a 2x improvement on an Aarch64 core.
Thanks