Blender Git Loki

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!

Cycles: Use new SSE version of offset calculation for all QBVH flavors

Gives up to ~1% speedup again.

While it seems to be small, still nice since the code now is actually more
clean that it used to be before.

Cycles: Add AVX2 path to subsurface triangle intersection

Similar to regular triangle intersection case. Gives about 3% speedup rendering
SSS object on my desktop,

Question: how to avoid such a code duplication in a nice way without speed loss?

Cycles: Cleanup, style

Cycles: Disable optimization of operator / for float3

This was giving some speedup but made intersection tests to fail
from watertight point of view.

Needs deeper investigation, but need to quickly get it fixed for
the studio.