Reviewers: , Description: Ordinarily, it's fine to have type coercion on function parameters, for example, if you pass a float where a color was expected, it'll just do the usual float-to-color

Reviewers: dev-osl_imagworks.com, osl-dev_googlegroups.com, Description: Array assignment was incorrectly clearing the derivatives of all entries instead of just the derivatives of the entry being

No problem - just wanted to make sure it is on the list. I realise you have more fundamental issues to sort out first! Simon

That's not actually true. We push when we first run the shader, and that doesn't change the runflags. And we need to, so that exit() will work correctly. I suppose we could have an optional

Yeah, I suppose that's more clear. Chris? Anybody else? Opinions? I'll put in a FIXME for now. -- Larry Gritz l...@...

I think it's not. I added it at one point that I was tracking down a bug and never removed it (figuring that it couldn't hurt, and might protect us from subtle bugs some day). I can remove

Seems like a good change. A few questions about the implementation: (maybe just needs more comments) http://codereview.appspot.com/204046/diff/1/6 File src/liboslexec/exec.cpp

Reviewers: , Description: adjust_varying is the function that doctors whether a variable is uniform or varying based on what is about to be assigned to it. But if a uniform is being assigned from

Hi guys, Nice job with the analysis Larry. It's interesting to see the kinds of runstates which come out of your renderer, especially the apparent predominance of really sparse states (at a quick

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

Reviewers: , Description: Like gcc, allow a "-E" option to oslc that just outputs the result of preprocessing. Please review this at http://codereview.appspot.com/201057/show Affected files:

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

Spans 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.) That may be a good compromise. I think

OK, so what do we make of all this? I've quoted a few interesting cases below. Most of the unique state patterns look like this, typical sparse runflags from secondary ray batches: runflags are

Next installment of "everything you wanted to know about runflags but were afraid to ask." So after sampling representative runflags from a frame with production shaders and assets, next I wrote a

OK, I've done some really interesting investigation the runflags issue. Chris Foster was very inspiring with his test program and span idea (which we've been debating versus Chris Kulla's similar

Thanks for the email, Simon! Yes, OSL already has primitive variables. I agree that it would be handy to have a built-in function that tells you if the particular value is the default, from a

Just wondering if you have thought about binding shader parameters to geometry like you can with primitive variables in RenderMan. Specifically - if you are going to do something like this - it

Which other cases do you think are broken? I can try to simplify, but it's a fairly complicated set of moving parts. I'll see what I can do. -- lg -- Larry Gritz l...@...

LGTM But I still think there are additional corner cases to both setmessage and getmessage that might be broken. Overall the logic in these ops is quite hard to follow ... is there anything we could