SIMD/SSE Instructions

[jitspoe]

Anybody here messed around with simd instructions/intrinsics? I just recently tried them for the first time and attempted to optimize some skeletal model code in Paintball2. I was able to get some pretty decent speed improvements (around 14% overall fps increase in a scenario with lots of player models), but I don't feel like I'm doing things as optimally as I could. I think I need to write a test app to just try a bunch of different functions and see how they perform. I'm having a difficult time finding reasonable information on each function. Either it's a 1 sentence, vague description, or a 20 page thesis that I don't feel like reading through.

Things I'd like to know:
How many cycles does it take to do a load and store vs a loadu and storeu? How many operations do I need to do before it justifies doing the load and store? How many cycles does it take to shuffle? Is there a better way of shuffling data around into a more vertical format?

I feel like I end up doing so much prep work to get the data into a simd-friendly format, that it negates some (or all) of the benefits of doing simd.

When I tried to use simd for lighting the model (lots of dot products), it ended up being slower.

I know most of this stuff can be done on the graphics card, but I kind of want to optimize for the (surprisingly common) case of people with fancy processors and crap video cards.

[revelator]

Doom3 uses it extensively though not the SSE3 paths since it seems its slower than the non SSE code (not only noted by id several sources points to it being a fact).

Could probably get some good stuff from its idlib if you had a look.

[jitspoe]

[jitspoe]

[jitspoe]

Another update:

Using the /fp:fast optimization makes the double and float performance the same (so this is probably something you should make sure you have enabled on your engines if you don't, since we generally care more about speed than precision).

I've managed to make the SIMD version faster than the others by changing the data structure of the normals. Instead of having an array of vec3's, I changed it to 3 aligned arrays of floats. This avoids creating the local float[4]'s, which I think was causing the biggest performance hit.

That said, though, storing the normals in that format isn't ideal for other calculations, and you couldn't pass those arrays directly to OpenGL (I don't think). So... meh... SIMD optimization is tough.

[r00k]

i found some sse code for things like square root and othe math lib replacement
if i detect sse at init will this simple asm code be faster than the normal functions?
i mean for quake1 is it much benifit
it looks like a simple cut/paste codewise

[revelator]

depends for engines like tenebrae it makes quite a difference because it calculates a lot of heavy stuff on the cpu darkplaces seems to get along with the macro math functions just fine though but its also a lot more refined than tenebrae was in its days. Quake2xp ditto since it uses glslang for the gfx intensive calculations.

Guess the only way to find out is benchmarking after changes and then compare results.

[jitspoe]

SSE is usually not a simple cut/paste. You have to set your data up so things can be run in parallel, and often the price you pay to load/store/shuffle data around is greater than the benefit you get. You may end up having to rearchitect data structures and all the code that uses them in order to see a benefit.

If you're talking about replacing a simple sqrt with the SSE version, then it's going to be slower. SSE instructions are set up to run 4 instructions at once (in the typical case of 32bit floats on __m128's). In fact, you couldn't just call a SSE function with a floating point value. You have to load it to the SIMD registers, then store it back to floating point values.

[Spike]

aye, sse is not good for dot products (unlike 3dnow), which are pretty common in 3d engines.
supposedly this stuff is meant to be improved with the sse4 instructions.
don't underestimate random transposes.
but yeah, avoid copying data from x87 to sse and back. if you use a little sse on your data, use a lot instead.
and yeah, glsl is prefered for calculating dotproducts for lighting, as well as skeletal transforms and stuff.

[revelator]

Still trying to wrap my noggin around multi threading, though Theres lots of implementations gcc/omp -> pthreads msvc equivalent -> winthreads Intel has there own version with even more optimization pragmas than msvc and some other Company i cant remember the name off uses a special pthreads syntax also. Compatibility is so/so Intels pragmas cannot be used by msvc without there package installed besides the
very basic commands msvc understands itself, andd the same goes for that other Company. Atm i think gcc has the upper hand when it comes to omp use unless you buy Intels compiler.

Interresting thing and a good point to support the discussion here is an example where a guy modified Doom3 to use omp/pthreads for multithreading and achived some very interresting results speedwise.
SSo yeah SSE definatly likes having a lot of data thrown at it

[revelator]

Sorry for the double Words in the above post, my keyboard needs a repair (mechanical razer blackwidow with the dreaded key chattering bug).

[jitspoe]

From what I've read, the new dot product "instructions" end up taking just as many (if not more) cycles as doing it with the old instruction sets. I'll have to dig into the 3DNow stuff. I didn't realize it was optimized for dot products. I find it kind of strange that SSE wouldn't have that from the beginning. It's kind of fundamental for vector math...

As far as multithreading goes (a bit off topic), a friend of mine was suggesting openmp. I haven't tried that. I've done a little with pthread (you can get a library so you can run it in windows). I've also used some #defines to allow me to use the same syntax for threading on different OS's.

[revelator]

Only brought multithreading into the discussion because off SSE thread handles (kinda need multithreadding to run stuff in parallel).

I Work with Mingw64/Codeblocks daily, MinGW64 has its own pthread library (winpthread) though the old one also Works fine.

[jitspoe]

[revelator]