Blender Git Loki

Cycles: Make display update concept more generic for scheduler

Just a variable naming.

The idea is to make it so communication of render result to Blender
for offline rendering more closely follows what is happening for the
viewport rendering.

Cycles: Refactor render buffer update in PathTrace

Do it as a part of update_display() part of the render work, which
allows to leave decision on when such update is needed to the work
scheduler.

Currently should be no functional changes.

Cycles: Disambiguate `delayed` variable

Cycles: Reduce overhead of GPUDIsplay update on CPU

Access KernelGlobals once, avoiding TLS access for every pixel of the
scanline.

Probably unmeasurable, but still nice to avoid unnecessary TLS access.

Fix crash with denoising on CPU

Must use unaligned since the current denoising passes are not ensured to be
aligned like other passes.

Cycles: Write samples count pass

Done from the path initialization function as it is a single kernel in
which it is known path will be terminated (if path was initialized, it
will be followed along and eventually terminated). So instead of doing
the write in every kernel where path terminates do it in the single
place.

Needed to pass render buffers along, but this is more of a technical
change.

The sample number is always positive, as we no longer have multiple
tiles rendering at the same time. Probably logic somewhere else can
be simplified now.

The pass is only available if the rendering did finish. This is due to
the way how PathTrace communicates passes to Blender side.

Cycles: Implement adaptive sampling filter for CPU

Lacking multi-threading, but it will come.

Cycles: Initial support of adaptive sampling

This change brings back main logic of adaptive sampling, which includes
the following:

- Samples count pass
- Auxiliary buffer which is used to indicate per-pixel sample stopping.

Missing parts of the implementation is the filtering and scaling of the
render passes.

There are further possible improvements, such as ensuring equality of
noise when multiple samples are scheduled on the GPU.

Cycles: Expose adaptive sampling filters via CPUKernels

The change includes moving some lines around, to arrange kernels
in a more clear and grouped way.

The CPUFunction invokation had to be modified to return auto type.
This way it's possible to return value from the kernel. It compiles
here with GCC. Didn't check whether this is something from newer
C++ standards. If so, we can do some declspec magic to deduct the
return type from the function type.

On one hand this is an extra indirection, but on another hand this
brings the following benefits:

- Benefit from microarchitecture optimizations.
- Exposes all kernels in a similar manner.

Cycles: Allow early outputs from the integrator initialization

The was never an early output happening in this kernel, so the issue
was never detected yet.

Need to keep path and shadow path next kernels initialized to 0 in
this case, otherwise the kernel scheduling will not terminate the
path. Using path termination call is not possible in its current
implementation by the looks of it, because there is no previous
kernel scheduled yet.

Solved by splitting the state initialization into two parts, allowing
an early output prior to the full initialization or even prior to the
ray initialization.

The thing which is good in this approach is that it also initializes
buffer access in the state, so that the adaptive sampling can access
it in the general manner to perform early output checks.

Cycles: Count possibly rejected camera rays as samples

Cycles: Make path tracer aware of adaptive sampling

No functional changes, just piping some information so that it can be
used in the following development.

Also make the scheduler aware of the adaptive sampling, with some
preliminary support of samples alignment.

Cycles: Make RenderScheduler more readable

- Improve terminology, sticking to the one used in other code.
- More comments and examples.
- Split logic into smaller utility functions.

Cycles: Make threading accessors reusable in PathTraceWorkCPU

Allows to reuse arena creation and kernel globals access between
various tasks such as path tracing, display buffer update, and
filtering.

This change also makes it so the display buffer update respects
the device threads limit.

Cycles: Schedule adaptive sampling filter

Takes care of the logic from the render scheduler. Need to properly
implement it on the PathTrace and PathTraceWork now.

Cycles: Remove buffer from KernelWorkTile

Also do minimal changes to adaptive sampling filter kernels to keep
things compiled.

Comment out filtering functions in CUDA device, similar to CPU device.

All this is to prepare a bit less entangled and messy basis for work
related on bringing the adaptive sampling within the new integrator.

Cycles: Restore integrator's AA samples update

The AA samples are not communicated from BlenderSync to the integrator.

This is something what should become more explicit or clear: maybe set
AA samples together with diffuse/glossy/etc in the sync, and/or make it
happen from `Session::set_samples()`.

For now restore old style code which happens in `Session::update_scene`
but cover it with comment and do it without condition.

Cycles: Multi-thread adaptive sampling filter on CPU

Cycles: Move AdaptiveSampling to integrator folder

The device_task was the wrong place for it. The new placement makes
it possible to start hooking up the adaptive sampling information to
the PathTrace.

There are some minor changes to make the class fit better into the
new rendering pipeline, also documentation is somewhat improved.

Cycles: Ensure none of adaptive filtering samples are "missed"

Force scheduled number of samples to path trace to not go past
any of sample at which filtering is needed.

On a very simple scenes this will harm occupancy of the device,
but it will ensure that adaptive sampling gives perfectly matched
results regardless of how fast the device is.