I tried to eliminate the "allocation" but there were subtle bugs. I can revisit after committing what I have. (Or, you know, somebody else could do it, too. :-) Good idea. Next round. Not

LGTM I have a few comments (see below) but they can be addressed in future reviews. 10% is not a bad speedup to start with. http://codereview.appspot.com/217043/diff/26/33 File

For some reason, the group wasn't CC'd on part of this thread. -- Larry Gritz l...@...

Good suggestions, I'll try some of these out today. -- Larry Gritz l...@...

Looks like a good start, but I was thinking of a few more optimizations. Did you try tracking stats about what % of params actually gets bound? That would less us know how much is on the table to be

Reviewers: , Description: This change, at Chris Kulla's suggestion, is to not fully bind parameters even when it's time to run the shader body, but rather to bind the parameters individually as they

Apologies if it seems like I ignored your earlier patch. I've just been so swamped with support for our own productions that little changes that did not affect the compiler releases we work with fell

Hum, this duplicates some of the issues I fixed several weeks ago in http://codereview.appspot.com/193074/show but doesn't include the changes I made to use boost::unordered_map, which I guess made

Reviewers: , Description: Pointed out by "crunchvfx" in http://code.google.com/p/openshadinglanguage/issues/detail?id=55 Please review this at http://codereview.appspot.com/209049/show Affected

I like the improvements. LGTM. See my comment about how you can simplify the switch statement. http://codereview.appspot.com/207090/diff/1013/1016 File src/liboslexec/opspline.cpp

'SKIP_KNOT_DERIVS' things, it later. derivatives of each Oh, and the spline type can also be varying. http://codereview.appspot.com/207090/show

Here's what I've done: * moved Dual2<float/vec3> operators to dual_vec.h * made knot-derivatives compile-time selectable with 'SKIP_KNOT_DERIVS' define. They default to on because I suspect

addressing comments http://codereview.appspot.com/207090/show

LGTM Having done this - did you have any more thoughts on the even lazier version that binds only those parameters that actually get used? http://codereview.appspot.com/207100/show

Reviewers: osl-dev_googlegroups.com, dev-osl_imageworks.com, Description: We had already been executing shader layers lazily (only as params are "pulled" from downstream shaders), but we started by

Aha! Well, I have made no further progress on the runflags/indices/spans issue, but I did finally get "lazy bind" implemented, and it shaves a whopping 25% or more off total render time for

Oh gosh, this is very surprising and disappointing. I do know that when I tried a partial implementation of this idea with aqsis' shader virtual machine ages ago I was getting speedups of 15% or so

Now I've spent nearly a week doing the comprehensive changes that allows a compile-time switch to select whether we use runflags, explicit indices, or spans. (Most of that time fixing the subtle bugs

Don't knock yourself out over varying basis (though if easy, please do), I was suggesting this only as a way to have a single image test show all the bases. -- Larry Gritz l...@...

That would make the basis "varying", which the code currently doesn't allow, but that can be changed. I'll make the change -- it shouldn't be tough to