[Radiance-general] Mesh Rendering Performance

[Greg Ward]

Hi Lars,

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.

As for clustering rays, this is not as easy as it may sound.  We  
would have to reorder the entire ray calculation in order to generate  
bundles of dissociated rays, as otherwise you naturally get a tree  
with many daughter rays generated for each parent diverging in all  
directions in your scene.  Grouping daughters together you get almost  
no coherence, and techniques for getting good ray bundles are fairly  
complicated.  (See for example, Matt Pharr, Craig Kolb, Reid  
Gershbein, and Pat Hanrahan, "Rendering Complex Scenes with Memory- 
Coherent Ray Tracing," Proc. SIGGRAPH 1997 <http:// 
graphics.stanford.edu/papers/coherentrt/>.)

-Greg

> From: Lars O. Grobe <grobe at gmx.net>
> Date: February 26, 2006 1:38:23 AM PST
>
> Hi,
>
> just tried out, replaces my meshes by obj2rad-oconv-generated  
> instances. May be faster, but now my rpict-process takes 1.4 GB  
> instead of 700 MB ;-) So I guess I will have to stay with those  
> "slow" meshes...
>
> CU Lars.
>
> P.S.: Concerning optimizations: I think trying to introduce  
> assembler into radiance code is a bad idea, as it breaks  
> portability, a great strength of the current code. Still, I think  
> one should think about if the code could not be written to be more  
> vector-friendly. Than compilers could do the rest (auto- 
> vectorization is even in gcc since 4.0), and those who want to try  
> (like me ;-) could simple replace some functions. Some ideas would  
> be like passing not only one ray, but ray clusters to the  
> subfunctions, so that these could be implemented to do calculations  
> in parallel. Another help would be to replace the unflexible  
> datatypes by unions. I ran into trouble when I just wanted to  
> Altivec some routines. As mat4, fvec etc are simply arrays, I have  
> to get the data in a altivec-suitable format, which causes  
> overhead. If they had been e.g. unions (containing nothing but an  
> array), I would have simply changed this to be an union of array  
> and vector. All unchanged functions would work as now, and still I  
> could directly apply altivec code on data. Those who think altivec  
> is out because Apple build x86: this year we might see the first  
> cell-processor machines. And vector units are built into almost all  
> platforms today.