[Bf-committers] Raytracer Optimization

[Timothy Baldridge]

I've been getting some complaints from some Irix users about degrading
performance in recent Blender builds. I was unable to duplicate these
claims but the results of my performance study have got me interested
in the Raytracer engine. It seems that on the test.blend file we're
spending close to 80-90% of the raytracing time in the octree search
algorithms. This leads me to wonder if we can do something about the
speed of these functions. From my call tree graph of the gprof data it
seems that all the octree routines and related code all reside in a
collection of 4 functions.

>From looking at the raytracer code, it seems that we are using a
octree algorithm. So, I'm interested in performing some tests of
optimization of this code by either implementing a new sorting
algorithm such as a BIH or kd-tree. Also CUDA optimization is
something I'd like look into as well.

What I'm wondering about though, is if optimizing the current renderer
is worth it. I have little interest in re-writing the entire engine,
since I don't have the time/knowledge to do this, but I am interested
in discussing with others and working with others on optimizing the
ray search algorithms. However, if someone is already rewriting the
engine from scratch this work may not be worth it.

So, as a starting point, I'd like to look into turning the ray search
algorithm into something that can be swapped out at runtime. So we
could have the stock octree method, a bih (or other search method),
and perhaps some hand optimized SSE methods. At any rate, we could
modularize the code to allow some experimentation.

Any thoughts, interest?

Timothy

-- 
“One of the main causes of the fall of the Roman Empire was
that–lacking zero–they had no way to indicate successful termination
of their C programs.”
(Robert Firth)