This is mainly useful for the render farms output when logging might stop at
the "Path Tracing Tile N/N" string, which makes it a bit difficult to follow
what exactly is happening (node going crazy, hardware issues or just last tile
is too much heavy).
This is more like an experiment, might be changed in the future.
They'll be checked for the version later and that check will fail anyway,
so better to not allow user to see unsupported device in the list.
Also corrected one more issue with the device enumeration.
Skipped devices did not reflect in the device number, which might result in bad
array indices.
This might also resolve T45037, and need to be ported to a release branch.
The main loop only handles transparent intersections from the camera ray.
Therefore we can simplify some things.
* Avoid PATH_RAY_CAMERA check, this is always true.
* Avoid path_state_next() call, we can just set transparent flag and increase transparent bounces. This way we avoid the function call and some branching.
Also remove debug num_ray_bounces++, this is incorrect here as no indirect bounce happens here.
Should be no functional changes.
Code there started becoming a bit too big, by splitting it up it'll make it
easier to do improvements or extending the features in there.
The layout is not totally final yet, would need to try de-duplicating parts
of code from split kernel with non-split integrators,
The issue was caused by using NotificationCenter which is only available
since 10.9 so trying to build blender on OSX with 10.7 SDK would fail.
Now it should be possible to build blender with SDK 10.7 and at the same
time official builds should still be doing proper weak-linking to a
notification center.
Older OSX has major issues with sincos() function, it's likely a big in OSL
or LLVM. For until we've updated to new versions of this libraries we'll use
a workaround to prevent possible crashes on all the platforms.
Shouldn't be that bad because it's mainly used for anisotropic shader where
angle is usually constant.
This fix is safe for inclusion into final Blender 2.75 release.
Glass BSDF was doing some magic with copying weigths from initial closure
onto refraction one and the code was not checking properly for the number
of closures.
TODO: We might want to refactor debug passes into PASS_DEBUG and some
debug_type (similar to Blender's side passes) to avoid issue of running
out of bits.
They're working just fine on AMD Tonga GPU and probably other architectures,
lets enable it under the experimental feature set and see what exact system
configuration gives issues.
This simplification is safe, as the call to volume_phase_eval() is guarded behind a CLOSURE_IS_PHASE check, which is equal to
CLOSURE_VOLUME_HENYEY_GREENSTEIN_ID. I don't think we will add more phase functions anytime soon, if at all.
This way it is now possible to select which exact debug pass is to be used
by the render engine. Accessible from the Passes panel.
Currently it could only be one debug pass, in the future we can make menus
and image users smarter and support multiple passes of the same type.
Quite straightforward implementation, but still needs some work for the split
kernel. Includes both regular and split kernel implementation for that.
The pass is not exposed to the interface yet because it's currently not really
easy to have same pass listed in the menu multiple times.
Round-up was only enabled for viewport render, which was for a long time hardcoded to
use 64 closures. This was done in order to avoid unnecessary kernel re-compilations
when tweaking the shader tree.
We could enable selective closure compilation in the viewport later if it'll give
measurable speed improvements, but even then round-up is to happen outside of the
device level,
This commit also removes early output which happened in cases when max closure did
not change. It was wrong because other requested kernel features might have been
changed.
This features are now based on the scene settings, so scenes without those features
used are rendered even faster.
This gives about 30% speedup on the AMD A10 APU here, but at the same time it does
not mean such an improvement will happen on all the hardware. That being said, the
Tonga device here seems to have no measurable difference.
In any case it seems handy to have for the future, when we'll want to support SSS
in the kernel or to port selective compilation/split kernel to CUDA devices.
The issue was caused by the reshuffle needed to make objects flags have proper
object's bounding box to solve regressions in SSS objects intersecting volumes.
There's actually a feedback loop happening here, which is now solved in quite
naive way -- for the true displacement we consider all objects are capable of
intersecting volumes, synchronize object flags prior to displacement shader
tasks runs and then re-update object flags for proper bounding box.
Not sure what will be the proper solution here, we can't do preliminary check
of intersection for displacement shader, but on the other hand we don't really
need this flag for displacement shader anyway.
This will help figuring out cases when node was not properly handled by the SVM
by aborting execution on CPU, where all the nodes are expected to be supported.
This commits finishes initial selective nodes compilation into kernel, which
helps a lot performance-wise for AMD OpenCL kernels.
Split by node groups is based on statistics from simple scenes like BMW and
more complex scenes like mango and gooseberry production files. Further
tweaks are always possible, but it should be a good starting point.
TODO: Still need to ignore unused nodes when calculating requested shader
features.
For now it's reported to the stdout, matching to the CUDA behavior.
In the future we can hide this into GLog logging once the kernels
are considered all stable and so.
Like Camera Motion, only available in the Experimental kernel.
This should be it for the upcoming release, we now support almost everything, apart from Transparent Shadows, SSS and Volume.
