In lieu of having a light path expression engine available, I made an attempt at implementing the same thing for AOVs in my own tracer (I haven't yet integrated full OSL shaders yet...baby steps). I t

Reviewers: , Description: New optimizations: * exec.cpp: when binding, only look up userdata if "lockgeom" is false! * constant folding of gettextureinfo! * peephole optimization of certain pairs of a

Post-optimization, yes! Consider: x -= origin; x *= scale; x += origin; That's totally reasonable. But if b is constant 1 (so middle instruction turns into nop) and x is unknown, you get the case I de

Please don't commit until I've had a chance to look this over. Will do tonight or tomorrow morning. -- Larry Gritz l...@... -- You received this message because you are subscribed to the Google Groups

OK, I've constructed several shading engines over the years, spanning 5 or 6 commercial renderers, and I was thoroughly convinced that it was essential to shade in batches in a SIMD manner. That is, s

Reviewers: , Description: Create OSL_NOBATCHES compile-time switch to hard-code the OSL interpreter to do one-point baches only (and take some shortcuts by assuming this). This works much like we prev

Remember when I did the single batch work, I speculated that with batched shading, the interpreter was probably accounting for somewhere around 25% of runtime, so if total render time doubled with goi

Reviewers: , Description: Our testsuite scripts currently operate this way: for each output of a test (let's call it 'foo') it does either a diff (if a text file) or idiff (if an image) of foo and ref

The issue is order of printfs, as well as how many times lines are printed (all uniform args prints only once per batch for SIMD). Consider this shader code: printf ("unif = %g", 0); printf ("vary = %

Reviewers: , Description: Can you believe all this time the ternary operator didn't compile correctly? I forgot to add the codegen routine for it! Also fixed a couple comments. Please review this at h

Unfortunately, we made a decision a long time ago that "uniform" things by definition have zero derivatives. So in many of our shadeops, the "uniform clause" just zeroes out the derivatives. A varying

Where we stand is best summarized by simply listing the shadeops left to do: non-closure: and area calculatenormal filterwidth fresnel getmessage gettextureinfo iscameraray isshadowray or reflect refr

Reviewers: , Description: Alter the OSL grammar slightly to allow function prototypes. Add lots of prototypes to stdosl.h (which is read upon startup automatically) and remove the corresponding table

I just did a commit of that oslc table stuff. Please note that the changes in stdosl.h require you to 'make nuke' after updating, if you find weird errors while compiling the shaders in src/shaders. -

I put the wrong reviewers address for this one and the mail didn't get through. Here it is: http://codereview.appspot.com/1667054/show Alex

The scheme generally LGTM. Specific comments, mostly minor, attached. It's ok with me if you want to keep the register_closure stuff now, then we can remove it later after I've finished the declaratio

Reviewers: dev-osl_imageworks.com, osl-dev_googlegroups.com, Description: The previous way of getting to the component had a nop GEP and then one that accessed the wrong address (beyond the object spa

Reviewers: dev-osl_imageworks.com, osl-dev_googlegroups.com, Description: With this little patch and this environment variables: USE_LLVM=1 LLVM_DIRECTORY=/Users/whoever/.../llvm/dist LLVM_VERSION=2.7

LGTM! http://codereview.appspot.com/1691048/show

LGTM -- Larry Gritz l...@...