You mean checking all the inputs? Sure. But let me check this one in first. -- Larry Gritz l...@...

How about checking the results of geometry binding as well? Otherwise LGTM http://codereview.appspot.com/194142/show

Reviewers: , Description: This change allows a debug mode (set by attribute("debugnan",1)) that checks every value written by each instruction, and if any nan or inf values are found, issues a

Right before checking in, I noticed that the same mistake could happen for ordinary loops: while (1) { } or do { } while(0); I just fixed in in both places in the identical way. -- Larry

Hi Jeremy, Sure, you can do it. It would be great. Oleg

On this one, I'll have to take your word for it. LGTM! http://codereview.appspot.com/195084/show

LGTM http://codereview.appspot.com/196043/show

Reviewers: osl-dev_googlegroups.com, Description: There was a problem with the sample function in beckman closure. A missing sqrt for sampling the tangent of theta. It was preventing reflections from

Reviewers: , Description: Bug fix: When a function's 'return' statement is not the last statement in the function body, we use a trick where we wrap the function in a 'do { ... } while (0)' and the

OK, I committed it, so give it a try. This should throw into even more stark relief the waste associated with sparse runflags. I'll tackle that after "rebind" is

Mcpp integrated pretty easily with the existing structure. I can send you the project I made for it. Unfortunatly I wasn't able to get it to build on vs with cpp syntax. I think it assumed some

LGTM2 Can't wait to see the difference on those benchmark cases. http://codereview.appspot.com/194117/show

LGTM http://codereview.appspot.com/194117/show

Reviewers: , Description: If you called context->execute() with a "sparse" set of runflags (such as if you were picking the subset of a set of rays that hit objects with the same shaders), it would

Hi Jeremy, I was trying to use the boost.wave preprocessor, but still have some troubles to integrate it. I was not able to run any tests so far. However, I'm still trying :-) Maybe it would be

I just checked one failed test file output and the error was ref: -5.96046e-08 out: -5.96046e-008 I wonder if this is due to different default precision on cout possibly? That was the only error so

I have made some modifications to runtest.py to allow for the tests to be run on windows along with some changes to the cmake files. I have redone the everything from scratch and have made changes to

http://codereview.appspot.com/195042/diff/1/5 File src/liboslexec/exec.cpp (right): http://codereview.appspot.com/195042/diff/1/5#newcode191 src/liboslexec/exec.cpp:191: VaryingRef<float> * valref =

LGTM - just a few small notes http://codereview.appspot.com/195042/diff/1/5 File src/liboslexec/exec.cpp

Reviewers: , Description: 1. Refactor "bind" to simplify the handling of globals. 2. Bug fix (exec.cpp:309) -- zero out local strings, the one place where uninitialized values in the heap can crash