Larry Gritz <l...@...>
The most important data point is that runflags are a big loser for the vast majority of run states that we see. So moving to one of the others (almost certainly indices) is at the top of my plate.
By the way, when we first opened OSL a few weeks back, we noted that we were working hard on optimization, still being 5-10x slower than our old C shaders. We've been working with a target production frame that was a bit of a worst-case scenario, which was slightly more that 15x slower than the equivalent frame with our old C shaders as of 3 weeks ago. At the beginning of this week, we had closed the gap on this scene to 3.5x (not counting changes from this week). Which we think means that less worst-case scenarios are probably getting very close to parity, and we are still working on more optimization, as you can see from this thread.
Some of that speedup was due to changes on the OSL side (all of which you have seen played out in reviews and checkins), but the lion's share was due to changing the renderer to batch the shading requests, including secondary rays. There are two big takeaways for you, dear readers:
1. Tales of OSL's inherent slowness where highly exaggerated. All along, most of the performance problem was due to our renderer's habit of shading one point at a time (despite liboslexec's being designed around batches). When we finally batched the points (especially secondary rays, even when we could only batch a few), and rewrote our integrator to be batch-oriented, we squeezed out a factor of 5 quite easily.
2. For those of you integrating OSL into other renderers, please learn from our mistake and use batches from the start!
On Feb 4, 2010, at 11:42 AM, Larry Gritz wrote:
On Feb 4, 2010, at 11:32 AM, Christopher Kulla wrote:--My interpretation of these results is that indices always win - unlessSpans only beat indices if there are is a single large span of 1's, or a large batch that is almost all 1's. (That's most primary batches, but nothing else.)