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

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

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

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:

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

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

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

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

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

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

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

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

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

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_imageworks.com, osl-dev_googlegroups.com, Description: Two small things I noticed while debugging something unrelated. 1) check_nan was off-by one 2) we allocate space for struct

uploaded wrong diff http://codereview.appspot.com/204077/show

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

How much "space" were we allocating for the struct placeholders? Should be 0, no? Or was the problem just that check_nan was reading bogus heap areas to check nans on these placeholders? -- Larry

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

I would have to check again, it seems to me the size was > 0. In any case, it seemed dangerous to give a valid heap address to symbols that should never be used. The nan fix is just that we were