Manta Interactive Ray Tracer Development Mailing List

Text archives Help


Re: [MANTA] simd intrinsic macro layer?


Chronological Thread 
  • From: Solomon Boulos <boulos@cs.utah.edu>
  • To: manta@sci.utah.edu
  • Subject: Re: [MANTA] simd intrinsic macro layer?
  • Date: Sat, 13 May 2006 16:43:58 -0600
I never finished the cross platform SIMD thing in Manta, but the one I'm using for DynBVH actually covers a lot more of the instruction set needed (the one in WaldTriangle only handles the instructions absolutely necessary for triangles). The biggest concern I had was getting that CSIMD implementation working so that systems without SIMD extensions (itanium, MIPS, etc) could still run code that was only implemented in SIMD.

I think I could fix that code to work at all optimization levels, but in the end it was really much slower than a regular C implementation of the same algorithm. The point of the CSIMD wasn't speed, but rather compatibility of code. I guess the question is whether or not it's actually a pain to have a C implementation of an algorithm if SIMD isn't available or as Ingo points out there aren't many systems that won't have a SIMD unit anymore. Another reason that the CSIMD might not be very useful is that it's good to have a C implementation to compare to when trying to figure out what the perf benefit of SSE or Altivec is anyway.

Solomon
PS - I'd like to vote for having two Manta lists. One for discussions like these and one for commit logs.


On May 13, 2006, at 11:27 AM, Aaron Knoll wrote:

Yeah that makes more sense. Either way, they'd have to be disabled for non-SSE systems.

-Aaron

On May 13, 2006, at 11:25 AM, Abe Stephens wrote:

Maybe it could go in the same directory as the header containing MANTA_SSE.... but I don't know where that is now.

Abe

Aaron Knoll wrote:

I see those in WaldTriangle, but that's it.

I was going to put a "simd.h" with these macros in Core/Math and then have everything else include that. Sound ok?

-Aaron

On May 13, 2006, at 11:16 AM, Abe Stephens wrote:

Solomon's macros are in there somewhere I think. He added some of the bvh stuff so maybe it is in those files.

Abe

Aaron Knoll wrote:

Right. I was thinking of a macros-only layer for now. Ultimately, I guess we'd use the original intrinsic for instructions that had different semantics across platforms (like reciprocal).

I wonder if we'll ever see operators for a standard simd type in libc or C itself...

-Aaron

On May 12, 2006, at 11:41 AM, Steven G. Parker wrote:

I am not opposed to it, but it should be done carefully (and measured) to ensure we don't lose performance.

Unfortunately, some things depend on the specific semantics of the instructions (like the saturating features of pixel conversion or the number of bits of precision you get from approximate reciprocal square root instructions), so it might not be portable in all cases.

Steve


On May 12, 2006, at 11:32 AM, Aaron Knoll wrote:

Would anyone be adverse to my putting a SIMD macro layer in Core? (So instead of _mm_add_ps we'd have add4, like in DynRT)

This could come in handy anyway if we ever need to hardware- abstract for the PowerPC's or Cell...

-Aaron












Archive powered by MHonArc 2.6.16.

Top of page