I'm aiming for gameplay more than graphics.
[/quote]
Definately don't bother untill after you've got the game play done and perfomance is an issue (if it ever is an issue).

Hi,

My chosen engine uses a fast math library which uses SIMD stuff if the processors in the hardware are up to the job. Makes alot of sense I suppose and the chapter explaining the source code sounded dandy. Only minor-ish issue is it's written in Intel so I'm having to convert it using AT&T syntax as I'm compiling using Code::Blocks IDE which is GCC. No big deal so far just a question of learning the different syntax. Most of the commands are even pretty identical.

But.... I noticed when actually looking at the code he only uses the SIMD stuff in two files, one for vectors, one for matrices. Ok fair enough most of the stuff in the polygon classes and all that are maybe not too math heavy, whereas obviously vectors and matrices are heavily used 1000's of times a frame I would guess or an awful lot anyway. The thing is that at least half - maybe more like two thirds! - of the alternative SIMD code paths are commented out!!! He says in the comments that for some reason they are running more slowly than the ordinary C++ stuff!

So my questions are in light of that information:

1)Should I bother using the SIMD parts of the math library? It would mean finishing the job I've started converting the Intel stuff into Extended ASM but that's no really big deal. It would also mean updating the code to accomodate the latest processors types from Intel and AMD. Again perfectly feasible given that I understand exactly how he acquires their personal information All that said - is it worth it? My games aren't likely to be very high poly I'm aiming for gameplay more than graphics.

2)Will writing the SIMD stuff in AT&T syntax and compiling with GCC be any faster than the Intel stuff used with Visual C++'s special _asm addon capabilities? Maybe that might solve the problem?

I am a little horrified to see half this code commented out especially after how good the chapter sounded and I really can't think why Intel assembly syntax would be slow. Maybe something in Visual is ruining the implementation?

Anyways.... thanks for any help offered as always

2)Will writing the SIMD stuff in AT&T syntax and compiling with GCC be any faster than the Intel stuff used with Visual C++'s special _asm addon capabilities? Maybe that might solve the problem?

I rewrote most of my math stuff into SSE a while ago and there was a pretty nice benefit. Converting my math code over was pretty simple, the matrix / vector stuff didn't take long at all. The amount of arithmetic was basically cut to 1/4th what it was in some cases.

Restructuring some other things took a little longer. It's a software renderer and one of the biggest gains in really geometry heavy cases was redoing the final transformation stuff for SSE. I ended up changing how I fill my vertex buffer to dummy up verticies to keep alignment and try to keep things ordered in a way that doesn't require me to shuffle it around. It just goes in and I'm off plowing through data. My first "get it working" attempt was to move from transforming 1 vertex at a time to the entire triangle. Alpha blended pictures worked nicely too since I can do multiple pixels at once.

I haven't really had any issues with SSE yielding slower results on my Q6600. I ended up just ditching the x86 stuff and leaving the SSE code because I had nothing but nice boosts.


VS 2008 generated some stuff for intrinsics though that was beyond earthly logic. 2008 would generate downright awful code like somehow create tons of loads and moves instead of a single movaps or optimize nothing at all. I had some stuff in assembly but that went out the window in 2010 because the compiler started beating me nicely. Even trying to improve on what it generated didn't work as well, so it was clearly playing into some kind of black magic that I couldn't hope to match myself.



Just try to do as much work as you possibly can when you're in SSE land. Don't be afraid to saturate the entire SSE register file, squeeze in as much as you can and do as much as you can before leaving.