Hi

I want to write an interface for math, that will hade SIMD. For now using xnamath.h which has SIMD, pseudo code:

Vector v = LoadSIMD( vector3_stored )

// do some operations on v

vector3_stored = StoreSIMD( v )

The reason for an interface, is so I can switch for another library, that maybe not platform dependet, and it may not have SIMD support,

so the question is, should the interface written in a general way that the use will now know if SIMD is being used.

Or should I maybe write something that they explicitly tell and use SIMD.

The last way creates problem, if writing specific code, for game or demo (anything!!!) then it must be written for different versions.

But this is easiest as implementation goes.

This is for 3D rendering, Vector, Matric, Planes, maybe something more.

Any insight or ideas are welcome

So more , like how would you people solve if this interface needed to be switchable for other math lib (any for that matter)

// I hope I expressed my self correctly ^^, also

// Thanks in advance

Layers are for cakes, not for software. Hiding the specific SIMD instructions behind a (very) lightweight wrapper can make sense. Hiding two different maths libraries, each with their own interfaces, behind a wrapper is plain insanity. It will just end being too heavily influenced by XNA maths, and the ported version will end up doing lots of work to just to make it work in the same way as XNAMaths.

1. Do you actually intend to port it later, or is this just wishful thinking? If the latter, just use XNAMaths directly.
2. If you are targeting multiple platforms, it's much easier to plan that support in from the start (and therefore, choose the right library now, not later).
3. If given a choice of "use SIMD" or "don't use SIMD", why would you ever choose the slow codepath?
4. Just put a minimum spec on your game (e.g. needs SSE3, Core 2 Duo and above).

Layers are for cakes, not for software.

I want this printed poster-size on my cubicle wall.

RobTheBloke

I'm tempted to actually use xnamath right as it is, the only thing I fear, is, if I would create like framework, based on that math, it would be almost impossible to port it,

even if I would write somewhat portable code. For example I want openGL support.

I've looked for different math libraries, as performance wise, they don't look impressive, (am I wrong maybe? ^^ haven't used them myself, just looked for performance reports made by others)

The reason for not using SIMD, is if an underlying math lib wont have SIMD.

I'm only familiar with xnamath, d3dmath and directx 10 rendering, as far as crossplatform goes, I have no clue about anything there, but would feel to explore that area at

some extent.

You can make a general solution along the lines of

VectorProcessor v(storedvector);

*do stuff on v*

storedvector=v;

Because if you do not do this, you are hiding information. This information hiding is ok for normal airthmetic which can not utilize it much, but something like SIMD can and there it matters, so you might as well provide that information regardless of wether the implementation can utilize it.

If you need multiple types of vectors (SIMD, normal), you could interpret that as vectors which need to process fast and vectors which dont. For example, another implementation could compress vectors which are not high performance (lol). Some implementation will use SIMD for high performance vectors which will probably have some effect on alignment requirements.

Having vector processing class thingys and different types of vectors based on intended use isnt making library dependent code, its just providing more information to utilize in the implementation.

Not sure if this works in practise though, like if you need to do some SIMD specific stuff outside the implementation for it to work properly (alignment for example)

I'm tempted to actually use xnamath right as it is, the only thing I fear, is, if I would create like framework, based on that math, it would be almost impossible to port it,

even if I would write somewhat portable code. For example I want openGL support.

XNAMath is not tied to D3D. You can use it with OpenGL as well. The only thing you can't do with it, is use it in linux/mac/droid/ios.

I've looked for different math libraries, as performance wise, they don't look impressive, (am I wrong maybe? ^^ haven't used them myself, just looked for performance reports made by others)

The performance of XNAMath isn't exactly mind blowing. It's better than your own FPU code, but it's not exactly a gold standard. Eigen is one of the better ones out there, and/or glm (although glm doesn't really do much more than the core GLSL math types)

The reason for not using SIMD, is if an underlying math lib wont have SIMD.

If you've gone to the effort of aligning your data structures such that they can use SIMD, there is no point in you choosing to link to a maths library that doesn't support it. It's nothing but works for works sake, and won't add any value to your code.

I'm only familiar with xnamath, d3dmath and directx 10 rendering, as far as crossplatform goes, I have no clue about anything there, but would feel to explore that area at

some extent.

Having an app that can work with D3D or OpenGL is non trivial. It's possible sure, but you will end up effectively duplicating the D3D10 headers 3 times (once for the generic interface, once for the OpenGL implementation, and once for the D3D implementation). In general try to hide platform specific code under an interface, but this might be easiest to do at the Mesh / Shader level, rather than the lowest possible level. To be honest, write a game that works in D3D. Write another game in OpenGL. Once you've got experience of both, then consider writing a lib that abstracts the two.

I think I will look at Eigen a little, if not too complex maybe will go with that. I guess there is some work to do ^^

thanks for your inputs people :D

Not sure if this works in practise though, like if you need to do some SIMD specific stuff outside the implementation for it to work properly (alignment for example)

Once again. Layers are for cakes, not for software.

VectorProcessor v(storedvector);  //< unaligned load
*do stuff on v*  //< op
storedvector=v; //< unaligned store

Any benefit of SIMD will have been eaten up in the additional loads/stores. There is no point in doing this. Either align your data and use SIMD properly, or simply don't bother and let the compiler attempt to do the best job possible (with the right compiler flags, it might just SIMD up some of your maths).

If you need multiple types of vectors (SIMD, normal), you could interpret that as vectors which need to process fast and vectors which dont.

So rather than having a single codepath for a vector3 cross product, you now have two codepaths. This effectively halves the amount of instruction cache available, and increases the the amount of time decoding instructions, and increases the size of your compiled code. One way, or the other, not both.