Reviewers: , Description: getmessage/setmessage working. I'm not 100% sure about closure messages, since we can't create any closures yet to pass! But I'll return to this and verify after the closure

The last dragon has been slain. Both OSL and Arnold testsuites full pass with the patch I'm about to commit! Next up: tweedle. -- Larry Gritz l...@...

Update for anybody who doesn't watch the commit list: To combat pesky performance problems of interpreting OSL, we've spent the past few weeks adding an LLVM back end to OSL. LLVM is an open source co

Reviewers: , Description: This fixes a minor bug so that OSL builds on systems without LLVM installed. Please review this at http://codereview.appspot.com/1860044/show Affected files: src/liboslexec/C

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

Reviewers: , Description: In the course of the merge, I broke displacement subtly when not using LLVM. This patch copies out P and N correctly for the interpreter, as we do for the LLVM path, so that

What is the best way to assign constant value for closure color variable? For example, I'd like to write a shader such like this. surface constant() { Ci = color(1, 0, 0); } Unfortunately, as spec 5.1

Reviewers: osl-dev_googlegroups.com, dev-osl_imageworks.com, Description: I forgot to cover the case of external closures in the merge code for ADD. This patch fixes the problem. Please review this at

Reviewers: , Description: Yet another fix to the P & N copying code for displacement to make the interpreter and LLVM work the same way -- don't "find" the symbol from a layer that never was bound. Pl

Reviewers: , Description: Component indexing wasn't creating the necessary temporary if the types didn't match. This caused the wrong code to be emitted for something like this: "int i = (int)P[0];" P

For anybody who will be at SIGGRAPH in Los Angeles next week, I'm giving a talk about OSL on Wednesday in the "APIs for Rendering" talk session (room 502B at 2pm). My sketch co-authors are Cliff Stein

Reviewers: , Description: This rearrangement of LLVM optimization passes approximately doubles the performance of the resulting code. Yes, I know it looks like all the pieces of the engine are splayed

For exactly these reasons, I'm not having this reviewed yet. I don't know if the strategy is very helpful, not least because it requires the interpreter to run flawlessly and interchangeably. Though a

Ci = color(1,0,0) * emission(); -- Larry Gritz l...@...

Incidentally, here are the counts of how many points were executed for each shader group in our tweedle test image, at 1/4 res but full sampling. 117 groups in the scene never executed (and thus never

Reviewers: osl-dev_googlegroups.com, dev-osl <dev-osl_imageworks.com>, Description: And also adding the backfacing() function for the shaders to be able to handle that directly. Please review this at

Reviewers: , Description: I've spent several days tracking down crashes in our LLVM-generated code, with little satisfaction. I still don't know if this reveals bugs in LLVM or that we have subtly mis

Effectively, yes. But it's slightly more complex than a simple revert, as it keeps the non-working newer version present but #ifdef-ed out, so I can refer it as we move forward to reconstruct the most

Reviewers: , Description: LLVM tweaks: I had commented out the doInitialization/doFinalization calls to the pass manager because they didn't seem to do anything useful. But on a hunch after some very

Reviewers: osl-dev_googlegroups.com, dev-osl <dev-osl_imageworks.com>, Description: We were calling noise functions osl_psnoise_dfdfdfff with the wrong type for the last two arguments. That was trigge