Replies: 3 comments 4 replies
|
I don't see anything about the types themselves that would keep them from being compiled with |
0 replies
|
You can check out this quick list of gotchas that I've run into here. It's mostly up to date. |
2 replies
|
I've been trying to make progress on this again.. I've gotten decently far but I hit into a snag with a ptr_offset_from intrinsic: I've managed to setup nalgebra like this in my no_std crate: Is this something we can get from spirv? |
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hey guys, I love the idea of the project. My question is if its possible to replace the glam:: types with those from nalgebra.
I prefer to use more mathematically based libraries (and nalgebra has glm-like wrappers too from
nalgebra_glm.It would be amazing if I didn't have to convert to glam::Vec types to pass around data for use on cpu/gpu shaders to minimize dependencies and keep my code paths clean and easy to understand.
I don't fully understand how the glam:: types get converted to SPIR-V, I looked a bit through the code and I couldn't fully find if there is any function/translation mapping going on.
Is this currently possible? Would it be a huge lift to do?
In addition to ergonomics, there are some cpu-side performance benefits of nalgebra on certain operations that are of interest.
All reactions