Blender Git Commits

Cycles: Fix OpenCL compilation with the new brick texture

Cycles: Fix missing underscore in geom_object.h

Cycles: Fix T49901: OpenCL build error after recent light texture coordinate commit

Basically, the problem here was that the transform that's used to bring texture coordinates
to world space is either fetched while setting up the shader (with Object Motion is enabled) or
fetched when needed (otherwise). That helps to save ShaderData memory on OpenCL when Object Motion isn't needed.

Now, if OM is enabled, the Lamp transform can just be stored inside the ShaderData as well. The original commit just assumed it is.
However, when it's not (on OpenCL by default, for example), there is no easy way to fetch it when needed, since the ShaderData doesn't
store the Lamp index.

So, for now the lamps just don't support local texture coordinates anymore when Object Motion is disabled.
To fix and support this properly, one of the following could be done:
- Just always pre-fetch the transform. Downside: Memory Usage increases when not using OM on OpenCL
- Add a variable to ShaderData that stores the Lamp ID to allow fetching it when needed
- Store the Lamp ID inside prim or object. Problem: Cycles currently checks these for whether an object was hit - these checks would need to be changed.
- Enable OM whenever a Texture Coordinate's Normal output is used. Downside: Might not actually be needed.

Cycles: Add smoothing option to the Brick Texture

This option allows to create a smoother transition between Bricks and Mortar - 0 applies no smoothing, and 1 smooths across the whole mortar width.
Mainly useful for displacement textures.

The new default value for the smoothing option is 0.1 to give some smoothing that helps with antialiasing, but existing nodes are loaded with smoothing 0 to preserve compatibility.

Reviewers: sergey, dingto, juicyfruit, brecht

Reviewed By: brecht

Subscribers: Blendify, nutel

Differential Revision: https://developer.blender.org/D2230

Cycles: More workarounds for weird crashes on AVX2

Oh man, is it a compiler bug? Is it something we do stupid?

For now more crap to prevent crashes. During the conference will talk to
Maxyn about how can we troubleshoot such weird issues.

Cycles: Implement texture coordinates for Point, Spot and Area Lamps

When using the Normal output of the Texture Coordinate node on Point and Spot lamps, the coordinates now depend on the rotation of the lamp.
On Area lamps, the Parametric output of the Geometry node now returns UV coordinates on the area lamp.

Credit for the Area lamp part goes to Stefan Werner (from D1995).

Cycles: Initialize the RNG state from the kernel instead of the host

This allows to save a memory copy, which will be particularly useful for network rendering.

Reviewers: sergey, brecht, dingto, juicyfruit, maiself

Differential Revision: https://developer.blender.org/D2323

Fix T49846: OpenCL rendering compilation failure

Cycles: Add optional probabilistic termination of light samples based on their expected contribution

In scenes with many lights, some of them might have a very small contribution to some pixels, but the shadow rays are traced anyways.
To avoid that, this patch adds probabilistic termination to light samples - if the contribution before checking for shadowing is below a user-defined threshold, the sample will be discarded with probability (1 - (contribution / threshold)) and otherwise kept, but weighted more to remain unbiased.
This is the same approach that's also used in path termination based on length.

Note that the rendering remains unbiased with this option, it just adds a bit of noise - but if the setting is used moderately, the speedup gained easily outweighs the additional noise.

Reviewers: #cycles

Subscribers: sergey, brecht

Differential Revision: https://developer.blender.org/D2217

Cycles: Another attempt to fix crashes on AVX2 processors

Basically don't use rcp() in areas which seems to be critical after
second look. Also disabled some multiplication operators, not sure
yet why they might be a problem.

Tomorrow will be setting up a full test with all cases which were
buggy in our farm to see if this fix is complete.

Cycles: Fix for fix (tm)

Sorry guys, for some reason read the expression back-to-front
and did wrong fix :S

Cycles: Fix compilation error of AVX2 kernel without SSE math

Cycles: Fix typo in previous commit for BVH improvements

Cycles: Completely disable transform SSE for now

Was causing issues on another frame.

On a tight schedule, disabling for now so artists are happy.

Still looking into root of the issue!

Cycles: Fix crashes after recent optimization commits

There is some precision issues for big magnitude coordinates which started
to give weird behavior of release builds. Some weird memory usage in BVH
which is tricky to nail down because only happens in release builds and GDB
reports all variables as optimized out when trying to use RelWithDebInfo.

There are two things in this commit:

- Attempt to make vectorized code closer to original one, hoping that it'll
eliminate precision issue.
This seems to work for transform_point().
- Similar trick did not work for transform_direction() even tho absolute
error here is much smaller. For now disabled that function, need a more
careful look here.

Cycles: Avoid branching in SSE version of intersection pre-calculation

Similar to the previous commit, avoid negative effect of bad branch prediction.

Gives measurable performance up to ~2% in tests here.

Once again, thanks to Maxym Dmytrychenko!

Cycles: BVH-related SSE optimization

Several ideas here:

- Optimize calculation of near_{x,y,z} in a way that does not require
3 if() statements per update, which avoids negative effect of wrong
branch prediction.

- Optimization of direction clamping for BVH.

- Optimization of point/direction transform.

Brings ~1.5% speedup again depending on a scene (unfortunately, this
speedup can't be sum across all previous commits because speedup of
each of the changes varies from scene to scene, but it still seems to
be nice solid speedup of few percent on Linux and bigger speedup was
reported on Windows).

Once again ,thanks Maxym for inspiration!

Still TODO: We have multiple places where we need to calculate near
x,y,z indices in BVH, for now it's only done for main BVH traversal.
Will try to move this calculation to an utility function and see if
that can be easily re-used across all the BVH flavors.

Cycles: Move QBVH near/far offset calculation to an utility function

Just preparing for new optimization to be used in all traversal implementation.

Should be no measurable difference.

Cycles: Enable SSE math optimization for AVX kernels

This gives about 5% speedup for AVX processors.

Benefit of such optimization on other microarchitectures is still
under investigation.

Cycles: Implement SSE-optimized path of util_max_axis()

The idea here is to avoid if statements which could cause wrong
branch prediction.

Gives a bit of measurable speedup up to ~1%. Still nice :)

Inspired by Maxym Dmytrychenko, thanks!