[Radiance-dev] vectorization data types

[Greg Ward]

OK, I see what you mean, now.  I haven't profiled the code recently,  
but relatively little time is spent in the matrix routines.   
Optimizing a ray tracer is really challenging, because bottlenecks  
are not easy to isolate.  A lot of time is spent in the various  
material shading routines, which are spread all over the place and  
not easy to simplify.  The only place where you can really focus  
effort is in the actual octree traversal code, and this doesn't  
vectorize at all.

-G

> From: Lars O. Grobe <grobe at gmx.net>
> Date: February 26, 2006 12:14:15 PM PST
>
> Hi!
>
>> I don't know quite understand how changing the struct's to union's  
>> would help in vectorizing the code -- you'll have to give me an  
>> explicit example, and this is probably one for radiance-dev.
>
> This is the altivec way, I am not sure about other vector processors.
>
> A common approach to integrate altivec in conventional code is to  
> keep using arrays. The problem is that data has to be aligned for  
> altivec. If it isn't, one has to do quite a lot of operations  
> before the actual computation. As on altivec machines, I hace a  
> type "vector", I can enforce alignment of data in an array by the  
> following:
>
> typedef union { float arrayData[4]; vector float vectorData; }  
> myVector;
>
> Now, I can still access elements in the array, but the compiler  
> will align the data, and for altivec, I can use the vector directly  
> without any shifts.
>
> I came across this when I found an old posting from Georg, who  
> proposed that someone could take a look at multmat, which is  
> perfect for altivec. But as mat4 and fvect are not aligned, the  
> overhead is too large to really optimize code without changing data  
> outside those functions.
>
> Finally, I feel I really HAVE to say that I am not a programmer,  
> if, the lousiest c and c++ "scripter" out there... ;-)
>
> CU, Lars