The original thread (http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=4&id=65014) is closed so let's ask here.

Out of curiosity I tried the code (on a P4) and I'm getting weird results. Grab the test here: http://www.codercorner.com/SSETest.zip

Now, can you tell me what results you get ? And what's wrong with the profiling ? Where are the "33 cycles" mentioned in the original article ? From what I get the SSE code is slower than the non-SSE version, and the intersection point is apaprently not always correct.

Ideas ?

- Pierre

Um, your program just spits out a boatload of result on the console. Not seeing any timings. I'd guess it's printf limited ;P
(i ran it on my athlon1800+ for curiosity)

yep, same here. just a bunch of coordinates.

(fflush?)

Errr, you have to run it inside VC7 for the window not to immediately vanish. It's obvious from the source code what the numbers are :) The 3 first numbers are the relevant ones:

First = number of cycles for an FPU, SAT-based ray-box test

Second = number of cycles for the SSE version from the mentioned COTD

Third = number of cycles for an FPU ray-box test (Woo algo)

The other numbers are the impact points found by the Second & Third methods. The First method is only a boolean test that doesn't compute the impact point (which explains why it's usually the fastest).

I'm wondering why the SSE code takes a crazy amount of time on my machine (~7000 cycles) instead of "33", as quoted in the COTD.

The alternative question could be: did anybody get significant *speedups* using that COTD ?

- Pierre

COuld it be that you compiled without sse support? I.e., sse might be emulated with the compiler settings you used.

Hey,

I had the same results as you, the SSE version was definately the slowest. Looking at the asm though, I expected to see some _mm_blah_blah style instructions but there were none... I don't know much about assembly other than the odd bit here and there though. Certainly no SSE stuff.

stoo

Okay, after a few minutes of intense staring I discovered the reason the SSE version was so damn slow:

You didn't initialize the .w components of min/max/orig/idir. The FPU code couldn't care less, but "whatever happens to be on the stack" apparently is inf/nan/denormal most of the time.

That levels out cycle counts a wee bit. Currently looking into why it's still far off from the 33 cycles, and why the result is sometimes incorrect, because I think the algorithm is basically correct.

In any case, most of the cycles spent in all three methods currently are due to CPUID serializing, but I guess NB wasn't set to 1 in the original test suite ;)

Ok, some testing later. I'm now using NB=1000 which gives me somewhat realistic timings.

With proper input values (i.e. no NaNs), the SSE ray/AABB intersection test levels out at about 89 cycles. When I comment out the "filtering" part, I arrive at 31 cycles using VC++. With Intel C++ 8.0, I get 75 cycles; so much for what was implied in the "if you have a decent compiler (wink wink, nudge nudge)" part.

Anyway, seeing as removing the "filtering" kills about 4 SSE instructions, I can only assume that the original author never really timed his code, atleast not on a P4 (though I don't see how a P3 would be much faster). The 58 cycles difference for the filtering are certainly in line with the experiences I've made with using floating point specials in general - infinites and denormals are slow in calculations. I definitely do not see any way this is going to run on an average of 33 cycles on my P4 with the way it's implemented, atleast not after looking over it some more. I've still not found out why it returns the wrong result sometimes, though frankly I haven't looked much.

On a side note, the paper the author refers to describes an algorithm that checks a 4-ray packet stored as 3 vectors (x0,x1,x2,x3), (y0,y1,y2,y3), (z0,z1,z2,z3) against a box. I see no value of 17 cycles mentioned anywhere in the paper; and using the pseudocode given as a reference, I very much doubt they arrive at 17 cycles for the whole test - 68 (or more) cycles for the 4 tests seems a lot more likely. This is all fine if it's ray packets you're working with, but not much help in a general scenario - though I guess a symmetrical version which tests one ray against 4 boxes could be divised, which would probably be more interesting outside of a raytracer setting (e.g. for collision detection).

I'd try the ray-against-4-boxes variant for SSE optimization, again with a "vertical" layout (i.e. (x,x,x,x),(y,y,y,y),(z,z,z,z) vectors). This tends to lead to much nicer code (basically just as you'd write a normal FPU variant, only you're dealing with 4 values at once), and be a lot faster aswell because you get tons less data dependencies, swizzling instructions, and perhaps most importantly, don't have to do annoying "merge steps" where you combine the results from several components of a vector into one field.

And again somewhat later...

Found the correctness problem. It was one of those "duh" things - when there is no hit, the two functions report different "intersection points". But since there is no intersection anyway, those values are pure junk. Setting the respective coordinates to 0 when there is no hit (in the outer loop ofcourse) gives the results one would expect.

I've also test-implemented the ray-against-4-boxes code. This is actually absolutely straightforward: (using the macros in the original ray-against-box SSE code)

What can I say ? As usual you rule, Fabian. Thanks !

- Pierre

What can I say ? As usual you rule, Fabian. Thanks !

- Pierre

Thanks guys, I was about to check/use this code too, and you guys saved me probably a lot of troubles!