Update testrender implementation of microfacet models to include the
improved visible normal sampling technique of Eugene d'Eon and Eric
Heitz (with improvements to numerical stability and continuity over the
code provided in the paper)

Add a stratified sampler to replace the basic monte carlo sampling
routine

Further simplify the math of the Oren-Nayar implementation

Switch to fast math routines to improve the consistency of results
across platforms
Fix sample implementation for weighted sums of brdfs, this was causing glass or other cases involving brdf mixtures to render incorrectly
Update affected tests
Delay timing of instance merging from ShaderGroupEnd until optimize time.

We used to do it inside ShaderGroupEnd. But this seriously messed up any
serialization! You'd expect a serialized version requested right after
declaration of a shader group to return an accurate representation of
what had been originally specified, not some unrecognizeable rewired
network with instances merged and shifted around (even though they would
be computationally equivalent).

So, by default, now we do instance merging right before we optimize the
group.  And just in case you want to force the old behavior (for example,
if you suspect that the as-early-as-possible merging was important for
memory savings), the "opt_merge_instances" attribute (which used to be
simple 0/1 for on/off) now accepts 2 to mean "do it, and do it immediately,
I know this means any subsequent serialization may not resemble the original
input."
Define operator!= for ConnectedParam and Connection.
We defined operator==, seems like the right thing to do, considering
we use != in a couple spots. I don't think that C++ will automatically
define one in terms of the other.
Skip skip LLVM code generation and execution for the interior shader group
nodes that have optimized down to nothing.

This also leads to a more robust test for whether a shader group does
nothing.  Previously, the test was too simplistic: is there only one
surviving instance layer, and does it generate an empty function.
Certain orders of optimizations (especially after instance merging)
could lead to interior shader group nodes that optimized to nothing, but
weren't quite eliminated. Now the test works, because we will avoid
making code for those unused interior nodes.
Minor refactor -- spit out compute_run_lazily() logic.
Also, recompute it after runtime optimization.
Minor improvements in some debug code and error messages.
Merge pull request #426 from lgritz/lg-serial

Change time of instance merging
Fix testrender and documentation to reflect that there is no longer an implicit factor of pi on emission()
Fix build
Fix namespace issue on isnan/isinf on OS X
Bug fix with instance merging -- never merge the group entry layer.

It turns out that it's a bad idea to do "instance merging" of the last
layer, also known as the "group entry" layer. It's very rare that the
circumstances would lead to it in any real world shader groups, but I
ran across it in a contrived layered example (with two layers of the
same shader master, no connections, same instance parameter values, no
outputs used) The bottom line is that the group entry layer must
generate a proper LLVM function, and having it marked as "unused"
because of merging leads to a cascade of hard-to-understand errors.
Allow renderer outputs to be specified as "layer.param".

This allows you to designate a named output to be a "renderer output"
(thus immune from unused output elision, among other things) only if it
is part of a particular layer, if you so desire. Of course, you can just
give a plain unqualified name, too, which would designate ANY outputs of
the same name (in any layer) as being so preserved, as it always has
worked.

As an example, this may come in handy if you have shader group where a
bunch of the instances have output parameters named "Cout", but only a
particular one is designated as needing to be queried by the renderer
after shader execution (so the others may be free to be optimized away).

Because this makes the instance->is_renderer_output() test much more
expensive (because it needs to concatenate the string), we also refactor
slightly so the "is it an output" test is done just once for each
instance param at the start of runtime optimization, the result stored
in a bit in the Symbol struct, so can be very easily tested the zillions
of times the optimizer may need to know.
Fix bug in assigning elements of struct arrays.

This kind of thing:

    struct S { float x; }
    S a[2];
    a[1] = a[0];

The generated code would not properly copy a[0].x to a[1].x.

LG is submitting this, but the patch is actually from Derek Haase.
LG confirms that it fixes the bug, doesn't break anything else, and
looks correct.
Spec: add a chapter explaining our standard serialization syntax for shader groups
Rebuild PDF spec
CHANGES and docs fixes
OSLQuery: reliably tell when no constant default is available for a param.

There's always been a 'validdefault' field in the OSLQuery::Parameter
structure, but it was always set to true.

* oslc -- add a %initexpr hint in the oso for parameters that are initialized
  by expressions (like myparam = u, or myparam = noise(P), i.e. is not a
  constant value at shader compilation time.

* oslquery -- if this hint is encountered for a parameter, mark its
  valliddefault = false.

Thus, a program using OSLQuery ought to be able to check the validdefault
field, and if it's true, the default constant is valid, but if it's false,
you can't count on the default constant being the true default.
Compilation error fix for strict compiler flags
Allow memory-aligned closure component classes

The root of the issue which this change is addressed to solve is related
on fact that sometimes external defined closure classes might want to be
aligned to some boundary in memory in order to utilize SIMD instructions.

Adding alignment attributes to such classes might give compiler some tips
about possible optimization (which are hidden to developer). And the issue
is that compiler thinks such classes are being allocated using genuine C++
allocation, which takes care of alignment. This case is being violated by
the ClosureRegistry which allocates closures in a pool.

With such way of class allocation it's nearly impossible to use SIMD in
the closure classes, because there's no way to make sure data is properly
aligned in memory.

One of the possible solutions is to not use SIMD in the closures, but
this becomes a real PITA to glue the SIMD logic of the rest of the render
engine with non-SIMD-aware storage of the closure itself.

Better solution is to make memory pool aware of memory alignment requests
and allow external engines to declare if the closure needs to be aligned
in the memory.

This commit tries to implement this logic, and it's more or less straight
forward.

To be mentioned, the SimplePool now allows non-aligned size to be allocated
in the pool. It seemed quite an artificial limitation which i'm not sure why
it'll give issues.

System aligned malloc functions doesn't have such limitation and this gives
some flexibility IMO.
credits