Shared source for Shader Lang and C++ about nabla HOT 6 CLOSED

this is not what you ask but maybe interesting
https://glm.g-truc.net/0.9.1/api/a00248.html

I googled "hlsl alike math library" and first result:
https://github.com/redorav/hlslpp

from nabla.

that lots of optimisations already done and tested

That's a rather bold assumption ;)

from nabla.

That's a rather bold assumption ;)

you no need to be rude. just decline and that it. Sorry if my suggestion was inappropriate.

I genuinely curious how current solution in Nabla better in terms of testing and optimisation compared to glm. Maybe I can learn something or we both. I have experience myself writing optimised vector and matrix operations with SSE and NEON, but then found that glm has pretty similar results.
Anyway, I don't expect you answering on this. that was out of curiosity and some willingness to help/share idk..

from nabla.

you no need to be rude.

That's not me being rude ;)

I genuinely curious how current solution in Nabla better in terms of testing and optimisation compared to glm.

Its not, replacing the vector math API is a TODO for the future.

I have experience myself writing optimised vector and matrix operations with SSE and NEON, but then found that glm has pretty similar results.

AFAIK, glm only has SSE optimizations for vec4 and mat4 and no NEON.

Whatever additional SSE and NEON is produced, is only produced by "autovectorization".

Basically the SIMD is an afterthought not a requirement from the start.

Furthermore, we find that whatever library we start using as a CORE (needed, not optional) dependency for the core or asset namespace we end up having to fork and maintain because its missing stuff or simply to fix bugs (except for the libraries we use for the asset loaders).

A recent example I can give is SDL2 which we've wanted to use to initialize our OpenGL contexts and load function pointers, unfortunately thanks to such beauties like this

static SDL_VideoDevice *_this = NULL;

we wont be using SDL2 for any required video functionality.

GLM is not something I want to fork and maintain.

from nabla.

@3d4m-vladimir we'll be moving to HLSL2021 in the near future.

Do you have any suggestions for a GLM-like library but which has an identical syntax/type names to HLSL ?

from nabla.

HLSL2021 does the job.

from nabla.