| Age | Commit message (Collapse) | Author |
|---|
|
Was missing feature detection in the BumpNode in the previous selective nodes
compilation commit.
|
|
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.
|
|
things. * SSS falloff now works.
|
|
|
|
|
|
|
|
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 is unused in the kernel, actual usage will come with
the next commits.
|
|
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.
|
|
Would exit, problematic for setting stereo3d modes which aren't always supported.
|
|
|
|
Same as last commit, code is unused and this one actually would have required some fixes,
as these variants output values outside the 0-1 value range, which doesn't fit Cycles shader design.
|
|
Let's finally delete this code, after 4 years of being unused,
there really is no excuse anymore.
If we decide to extend the procedural textures in SVM, we can do this anytime in the future.
|
|
|
|
This commit re-shuffles code in split kernel once again and makes it so common
parts which is in the headers is only responsible to making all the work needed
for specified ray index. Getting ray index, checking for it's validity and
enqueuing tasks are now happening in the device specified part of the kernel.
This actually makes sense because enqueuing is indeed device-specified and i.e.
with CUDA we'll want to enqueue kernels from kernel and avoid CPU roundtrip.
TODO:
- Kernel comments are still placed in the common header files, but since queue
related stuff is not passed to those functions those comments might need to
be split as well.
Just currently read them considering that they're also covering the way how
all devices are invoking the common code path.
- Arguments might need to be wrapped into KernelGlobals, so we don't ened to
pass all them around as function arguments.
|
|
It was kept disabled due to render artifacts which weer in fact caused by bad
memory access, which is fixed in the previous commit.
We now also can make it enabled in regular AMD split kernel after someone tests
the updated code.
|
|
The issue was caused by underallocation of object motion related arrays,
which happened by accident.
|
|
for Cycles UI
|
|
|
|
|
|
The code was failing to compile on runtime because of some path differences,
and it seems we don't need to specify full path to the file which originally
seemed to be needed to make include directives expansion working correct.
|
|
This was broken after the kernel file restructure.
Variables allocated in the __local address space can only be defined
inside a __kernel function.
We probably need to solve this a bit differently once we do the CUDA
kernel split, but this fix shoud be good enough until then.
|
|
Value was not set, moved it out of the constructor into
device_opencl_create() now.
|
|
|
|
Since the kernel split work we're now having quite a few of new files, majority
of which are related on the kernel entry points. Keeping those files in the
root kernel folder will eventually make it really hard to follow which files are
actual implementation of Cycles kernel.
Those files are now moved to kernel/kernels/<device_type>. This way adding extra
entry points will be less noisy. It is also nice to have all device-specific
files grouped together.
Another change is in the way how split kernel invokes logic. Previously all the
logic was implemented directly in the .cl files, which makes it a bit tricky to
re-use the logic across other devices. Since we'll likely be looking into doing
same split work for CUDA devices eventually it makes sense to move logic from
.cl files to header files. Those files are stored in kernel/split. This does not
mean the header files will not give error messages when tried to be included
from other devices and their arguments will likely be changed, but having such
separation is a good start anyway.
There should be no functional changes.
Reviewers: juicyfruit, dingto
Differential Revision: https://developer.blender.org/D1314
|
|
Was already done for CPU devices, now we also do this for OpenCL.
|
|
|
|
Split kernel is mainly useful for GPUs which can not support OSL in visible
future anyway.
|
|
No functional changes, just better to keep all atomic function in a single place,
they might become handy later.
|
|
|
|
They were lost during simplification of kernel loading but might be rather
crucial for the performance.
Also made it so cflags are shared across kernels. Surely it might lead to
some unwanted kernel re-compilation but at the same time they might easily
run out of sync with the changes in kernel and so.
|
|
|
|
|
|
|
|
No functional changes, just helps grasping what operations are actually
supported.
|
|
Also add depsgraph & physics
|
|
In certain configurations (for example when start resolution is set to small
value for background render and progressive refine enabled) number of tiles
might change in the tile manager. This situation will confuse progressive
refine feature and likely cause crash.
We might also add some settings verification in the session constructor, but
having an assert with brief explanation about what's wrong should already be
much better than nothing.
|
|
This changes the progressive refine part, regular update was already checking
for whether callbacks are set.
|
|
|
|
exactly one single root element"
|
|
That is needed for Motion Blur and Render Passes to work properly.
I hope there are no nasty side effects, but we need to test this.
|
|
Only enabled for the Experimental kernel though, so the feature set must
be changed in the UI to use the features.
|
|
|
